0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

プロンプトをこねるのに疲れたので、AI専用のデータ構造を定義して『指示のだるさ』を解消する

0
Posted at

はじめに

AIエージェントにUIデザインベースでコードを書いてもらう。
いい感じのコードが出るまで、プロンプトを少しずつ変えてAIガチャする。

運良く「当たり」を引けても、顧客からの「思ってたのとちょっと違う」という一言でやり直しが発生。

何度もガチャのたびに微妙に結果がブレるし、AIが勝手に読み替えレイアウトを盛大にぶっ壊したりもする。
戻せはするが微妙に融通が利かない。とてもだるい。

かといって業務量多すぎて人手ではとても間に合わない。

ということでプロンプトと一緒に投げるソースファイル自体の概念(思想)から考えることで、この問題を解消する。

ファイル構造でAIを「縛る」

プロンプトで頑張るのをやめた理由
プロンプト(言葉)はどこまで行っても曖昧です。
どれだけ丁寧に指示を書いても、AIはコンテキストの隙間を勝手に「推論(=空気を読む)」で埋めてしまいます。
その結果がAIガチャであり、レイアウトの崩壊です。

だから、AIに「推論」させる隙を与えないために、ソースファイル自体を以下の3層に分けて定義することにしました。

1. Context(前提条件の強制)

AIに対し、技術スタックやルールを強制するレイヤーです。

  • やり方: JSDocなどのコメントを利用
  • 中身: 「Tailwind CSS v4を使う」「shadcn/uiを使う」「解像度は1920x1080」といった「絶対に守るべき外枠」を明文化
  • 効果: AIが「どのライブラリを使うべきか」を勝手に推論して自爆するのを防ぐ

2. Implementation(人間が見るためのコード)

私たちが普段見ている、そのまま実行可能なコード(TSX等)です。(別にTSXじゃなくても何でもいいです。)

  • 役割: 人間が読解・修正し、AIが生成・変換を行う対象
  • ポイント: 従来のコード資産と互換性を保ちつつ、AIが「今どこの話をしているか」を特定するためのID(nodeIDなど)をコメントで添える

3. State(AIがカンニングするための事実)

ここが一番重要です。GUIの状態や不変の値を、構造化データ(JSON)としてファイル内に隠し持ちます。

  • 役割: 真実の単一ソース (SSOT)
  • 効果: プロンプトで「ボタンの幅を少し広げて」と曖昧に言っても、AIはこのState(事実)をカンニングして、精密に数値を書き換え。 AIの「気まぐれ」を物理的に封じ込めるためのアンカー

あまり内容は変わりませんが具体的な記載はGitHubの方をご確認ください。
(ベースの考え方を変える気はあまりないのでおそらくそんなに編集はしない。)

実例(試験的)

実際に上記の概念(思想)をファイル定義として落とし込んでみたものになります。
このファイルはWebのモックアップとして画面サンプルを作る際のデータとして定義しています。
.moc ファイル形式仕様書(日本語)
.moc ファイル形式仕様書(英語)

実際問題としてこれらの概念で作成するファイルは人間が手書きをするのは 正直非効率的 でGUIアプリケーションなどから生成することを前提としています。

ただ、自作のアプリケーションなどからこれらの概念を組み込んだ場合、非常に効果を発することになります。

例えばこのようにアプリケーションでデザインし、左上のボタンに対し付箋で指示をするような項目を記載して.mocファイルを生成AIの指示で添付として付けます。

アプリケーションでのUI作成画面
mocoker_img.png

※画像は開発中のアプリケーションのものになります。

指示プロンプト
gemini_prompt.png

指示をして出力されたhtmlを開くとこのような感じになります。
gemini_html_output.png

まだアプリから.mocファイルへの生成自体が完璧ではないのでボタンやテーブルなどは完全再現とまではいきませんが、ボタンの色変え変更指示なども再現されていますし、この程度であれば微調整の範囲かなと。
TSX→HTMLでこの程度の精度なのでそのままReactなどであればかなり効果的だと思われます。
特にプロンプトが雑で済むのが良いです。

また、背景情報を知らないGeminiの一時チャットモードでこれなので、プロジェクト情報を読み込めるClaude Codeやその他開発用ツールでやればほぼ100%再現は固いです。

これからやりたいこと

結局のところ、私が欲しかったのは 「AIをガチャではなく、人間の意志をくみ取って正確に形にする道具」 です。

現在はWebのモックアップ作成(.moc形式)をベースにしていますが、この思想は「AIに文脈を誤解されたくない」あらゆる場面で転用できるはずです。
例えば

  • 社内SEとしてのツール開発: 複雑な業務要件(画面設計)をStateに閉じ込め、AIに出戻りなくコードを吐かせる
  • Windowsデスクトップアプリ: スケジュール管理やKanbanなど、GUIの状態とロジックを密結合させたい場面

現在、この思想を活用するためにGUIでWebフロントエンドのモック作成用ができるVSCode拡張機能 「Mocker」 を開発中です。

最後に

今回、開発中のアプリで試して結構いい感じだったので今後開発するアプリとかにこの思想入れ込んでいくと仕事が楽になる…といいなぁとは思いますね。
設計業務が多いのでさっさとモック作成するアプリ完了させて、せめて画面設計の地獄からは解放されたいところですね。

この記事でいいなと思ったら評価とかGitHubのスターとかよろしくお願いします。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?