制御記号はAIに書かせろ。人間は仕様を決めろ。

はじめに

昨年12月に、「【脱・初心者】AIへの指示を『構造化』する魔法の記号たち」という記事を書きました。ありがたいことに、今でも多くの方に読んでいただいています。

その記事では”[]（角括弧）：ラベル付け、# （シャープ）：見出し、: （コロン）：定義”など、プロンプト作成における実践的なAI制御記号について説明しました。しかし8ヶ月も経つとAIエージェントの進化のスピードに記事の内容が追いついていない。また、実運用はここからさらに進歩している。

AIオーケストレーションを日々組んでいる立場として、いま最も効率的でアウトプットが正確だと感じている、AI運用のやり方について整理しておきます。

GeminiでGASのツールを作るとき。Claude CodeでAPPを作るとき。

最初にやるのは、壁打ちだ。ここでは、まだコードを書かせない。成果物の目的に応じて、私はChat GPTやGeminiを多用している。

何を作るのか。誰が使うのか。何のためなのか。ここをまず決める。決まったら、設計へ進む。

成果物の目的、基本思想、方針、利用環境、業務フロー、優先順位、制約、そして「やってはいけないこと」まで、すべて合意しておく。

実装AIへ渡すプロンプトは、人間が一から書かない。壁打ちAIに書かせる。ここがミソだと思っている。

理由は単純。壁打ちAIは、それまでの対話の中で、「なぜそうするのか」「何を捨てたのか」「どこが重要なのか」「何を勝手に変えてはいけないのか」まで、すでに知っている。

人間が最後にMarkdownを手書きすると、せっかく積み上げた文脈を要約する過程で、大事な部分が抜け落ちたり、プロンプトが細切れになり、実装AIが全体像を誤認する原因にもなる。

壁打ちAIは、私との長い対話を、目的、前提、基本思想、機能要件、非機能要件、制約事項、禁止事項、完成条件へと変換できる。

つまり、人間は意味を決める。AIは仕様へ変換する。意味の積み上げに要した時間は、AIに還元してもらえばいいと都合よく解釈している。

実装が終わっても、動いたから完成、ではない。

「アウトプットがイメージと違う」「挙動が怪しい」「勝手な解釈が入って答えがブレている」——そう感じたときに、実装したAI自身だけにレビューさせてはいけない。

設計書と成果物を、別のAIに渡す。「仕様と違うところを探せ」「意図しない変更を探せ」「既存機能への影響を見ろ」と指示を出す。そのレビュー結果を、実装担当のAIへ戻す。

つまり、複数のAIに役割を分担させる。

壁打ち → 設計 → AI向け仕様書生成 → 実装 → 別AI監査 → 手直し

なぜこの手順が重要なのか。

我々が思っている以上にAIは思い込みが激しく、自分の思考に引きずられることが往々にしてあるからだ。その逆もまた然りで、人間も気付かぬうちにAIに解釈を誤らせる指示を出していたりする。

第三者の目を必ず通すこと。すべての仕事に共通するプロセスです。

今回はアプリやツールにフォーカスしましたが、文章作成でも流れは同じです。

思考を整理しながら、文章の骨子をまとめる。ブログ記事の執筆では、自分でプロンプトを書くことがほとんどですが、提案書のような、より仕様が複雑なものでは、AIにプロンプトを書かせています。

そして、自分のレビューを経て、ファクトチェックと文脈補正を行い、執筆担当のAIへ戻す。

一見、手順が多く感じるかもしれない。でも、「手戻り」を減らしながら完成度を高めるには、これが一番の近道だと思うし、条件が決まったなら、AIに伝わる形へ直す仕事まで、人間が抱える必要はない。

要は、「良いプロンプトを書くこと」が目的ではく、「良い仕事の条件を決めること」が目的だからです。

この記事を書く数日前に、GASで業務分析のツールを作りました。壁打ちはChatGPTと行い、仕様を決め、プロンプトを渡してGeminiに実装させる。

ツールを作成中、今後の流れをまとめるようGeminiに指示を出したところ、GitHubでバージョン管理しろと言い出しました。

「いや、そんな大袈裟な……。」と思ったが、彼は至って真面目。そう考えてはみたものの、Gitへのコミットは、いつもClaude Code任せ。

「やりかた忘れたがな……。」

今回は、Google Drive側で履歴を残すことにしました。

「後捌きは、AIに任せろ。」笑