なぜ優れたAI制御はプロンプトではなく「入口設計」になるのか

Jul 18, 2026

1 min read

1 views

84%

いま本当に問うべきことは、AIに何を言うかではない

AIエージェントを使いこなすうえで、多くの人はまだ「どういうプロンプトを書けば賢く動くか」を考えている。だが、もっと本質的な問いは別にある。このエージェントは、どんな条件のときに、どの仕事を、どの入口から始めるべきか。

この問いは、単なる文言調整ではない。むしろ、ソフトウェア設計そのものに近い。人間が実務でつまずくのは、たいてい「何をやるべきか」が曖昧だからではなく、「いつ、どの責務で、誰が動くべきか」が曖昧だからだ。AIも同じで、能力の高さよりも起動条件の設計が成否を分ける。

ここで面白いのは、AIエージェントの話が、古典的な開発手法やルーティング設計と自然につながることだ。BDDがコードの正しさではなく、システムの振る舞いを問うように、AI Skills も単なる命令文ではなく、期待されるふるまいの入口を定義する。そして Laravel のルーティングが、リクエストをただ受けるのではなく、型に合うものだけを通すように、AI もまた「何でも受ける箱」ではなく、意味の合う入力だけを適切な機能に流す仕組みとして設計されるべきなのだ。

プロンプトは願い事に近い。入口設計はシステム設計に近い。

この違いを理解すると、AIの使い方が一段変わる。よいエージェント運用とは、賢い文章を投げることではない。意味の境界を作ることである。

プロンプトが壊れやすいのは、言葉が曖昧だからではなく、責務が曖昧だから

LLMは強力だが、決定論的な関数ではない。文字列が含まれていたら必ず起動する、というような単純な世界ではなく、文脈の意味で動く。だからこそ、同じ「セキュリティレビューして」という依頼でも、何を指しているのかが曖昧だと、起動すべき機能がぶれる。

ここで起きている問題は、自然言語の曖昧さそのものというより、責務の重なりだ。たとえば「security issues」と「security audit」が同じ領域を指しているのに、分け方が不十分だと、AIはどちらを選ぶべきか迷う。これは人間組織でもよくある失敗で、部署名はあるのに責任範囲がかぶっている状態に似ている。結果として、誰もが少しずつやるが、誰も最後まで持たない。

AI Skills の設計で重要なのは、説明を長くすることではなく、用途を鋭く切ることだ。たとえば次のように役割を分ける。

Use when: PRの差分をレビューするとき
Use when: プロジェクト全体を監査するとき

この分離は、単なる整理術ではない。AIの振る舞いを制御するための境界条件だ。曖昧な命令文を磨くより、起動すべき状況を明示するほうが、結果は安定する。

Laravel のルーティングが示すのも、まさにこの発想だ。たとえば Implicit Enum Binding では、ルートの一部が有効な Enum 値に一致したときだけ、そのルートが実行される。つまり、リクエストは何でも受け入れず、型に合うものだけが処理に進む。これは単なるフレームワーク機能ではなく、設計思想そのものだ。

AIにも同じことが言える。エージェントに「なんでもやって」と頼むのではなく、この入力ならこの技能、この状況ならこのワークフローと決めることで、振る舞いは初めて再現可能になる。

BDDとEnum Bindingに共通するのは、「正しさ」ではなく「適合」を見る視点

TDDは、コードが正しく実装されているかを確かめる。BDDは、システムが期待通りに振る舞うかを確かめる。ここで重要なのは、BDDが単にテスト手法を変えたのではなく、評価の軸を開発者視点から利用者視点へ移したことだ。

この視点の転換は、AI Skills の設計にそのまま応用できる。Skill は「中で何をするか」より、「外から見てどんな状況で発火し、どう役立つか」が先に来るべきだ。なぜなら、AIの出力を評価するのは、しばしば人間の利用文脈だからだ。コードレビューでも、要約でも、コミットでも、ユーザーが知りたいのは内部実装ではなく、期待した成果が得られたかである。

ここで Laravel の Enum Binding を重ねると、さらに見えてくるものがある。Enum は、入力を「意味のある値の集合」に制限する。これは、処理を始める前に「この値は業務上の候補として妥当か」を判定しているのと同じだ。つまり、入力の正当性を先に確認することで、下流のロジックを単純にする。

AI Skills も同じで、起動条件を先に設計すると、あとのワークフローは驚くほど安定する。たとえば、以下のような設計を考えてみよう。

ユーザーが「リリースノートを作って」と言う。
エージェントは、変更履歴から要約 Skill を起動する。
その Skill は、対象範囲が明確なときだけ動作する。
範囲が曖昧なら、勝手に推測せず確認質問に切り替える。

ここで大事なのは、AIに自由を与えすぎないことではない。むしろ逆で、自由に推測させる場所と、推測させない場所を分けることだ。BDD が「どんな振る舞いが正しいか」を対話的に定義するように、Skill もまた「どんな状況で何をするか」を明文化することで初めて、期待と実行が一致する。

良い設計とは、AIに賢く考えさせることではなく、賢く迷わせないことだ。

最も強い制御は、ルールではなくワークフローに宿る

ここで一つ、かなり重要な転換点がある。AIの制御をプロンプトでやろうとすると、私たちはつい「どう書けば従うか」を考える。しかし、実際にはLLMは意味で判断するため、単純な文字列一致のようには扱えない。だから、細かい命令の積み上げで制御するほど、むしろ不安定になる。

では、何で制御するのか。答えはワークフローだ。

ワークフローとは、単に手順書という意味ではない。誰が、いつ、何を見て、どの条件で次の行動に進むかを定義した、行動の地図である。AI Skills はこの地図の中の分岐点として機能する。たとえば、コミットすべきとAIが判断したら自動で Skill を起動し、ユーザーが明示的に呼んでも同じ挙動になる設計は、まさに自動と手動を統合したワークフローだ。

この考え方は、ソフトウェア設計では非常に強い。なぜなら、振る舞いの信頼性は、局所的な賢さではなく、入口から出口までの流れの整合性で決まるからだ。人間でも、優秀な個人が一人いるだけでは組織は安定しない。仕事が適切なタイミングで適切な担当に流れる仕組みがあって初めて、再現性が生まれる。

AI運用でも同じだ。優れたプロンプトは一回の成功を生むかもしれないが、優れたワークフローは成功を何度でも再現する。ここに、プロンプト時代とワークフロー時代の差がある。

入口設計を考えるための3つの層

AI Skills を本当に使いこなしたいなら、次の3層で考えるとよい。

意味の層: これは何をする機能か。レビュー、監査、要約、提案など。
条件の層: いつ起動するか。PR差分、全体監査、コミット前、ユーザー明示など。
責務の層: 何をしないか。別の Skill と重なる領域はどこか。

この3層が揃うと、AIは単なる会話相手ではなく、業務の流れに組み込める部品になる。Laravel の Enum Binding が値の集合を閉じるように、Skill もまた責務を閉じることで強くなる。

うまくいくチームは、AIにも「作る、試す、正す」を適用する

AI Skills の設計で最も誤解されやすいのは、最初から完璧に作ろうとすることだ。だが、意味ベースで動く仕組みは、机上の設計だけでは詰め切れない。実際に使ってみると、想定外の起動や、似た Skill との競合が必ず起こる。

ここで効いてくるのが、作る、試す、正すという反復だ。まず最小限の Skill を作る。次に、実際の業務フローで動かす。そこで見えたズレをもとに、description を調整し、責務を切り直す。このサイクルは単なる改善手法ではなく、AIの特性に合った設計プロセスだ。

考えてみれば、これは BDD の実践とも似ている。Given, When, Then でシナリオを書き、期待と実行のズレを対話で詰めていく。重要なのは、仕様を固定することではなく、期待の境界を明らかにすることだ。AIエージェントは、明確な境界の中では驚くほど有能だが、境界が曖昧だと、賢さが逆にノイズになる。

だから、Skill 設計の成功は、優れた文章力よりも優れた観察力に近い。どんな言い回しで起動するかではなく、どの状況で起動してほしくないのかまで見極める必要がある。起動条件を削るのは一見地味だが、実運用ではこれが最も効く。

実装より先に決めるべきこと

もし今、AI Skills や自動化の設計を始めるなら、まず次を決めてほしい。

この機能は、どの業務文脈で価値を出すのか
どの状況なら、必ず起動してほしいのか
どの状況なら、絶対に起動してはいけないのか
似た機能と重なる場合、どこで責務を分けるのか

これらを決めずに説明文だけ増やすのは、地図なしで標識を増やすようなものだ。道案内は増えるが、迷いは減らない。

Key Takeaways

AI制御の主戦場はプロンプトではなく入口設計 起動条件、責務、分岐を明確にすることで、AIは安定して働く。
Skill は長い説明文より、鋭い用途定義が重要 「Use when」を中心に書き、何をするかより、いつ使うかを先に決める。
BDDの視点はAI設計にそのまま使える コードの正しさではなく、期待される振る舞いを基準に考えると、業務への適合度が上がる。
Enum Binding は良いメタファーになる 有効な入力だけを通す設計は、AIの曖昧な判断を下流に持ち込まないための強力な考え方。
最適化は一発で終わらない 最小構成で作り、実運用で試し、競合や誤起動を見て正す。この反復が最終的な品質を決める。

入口を設計できる人が、AI時代の設計者になる

AIの時代に必要なのは、もっと長く指示を書く力ではない。意味の境界を設計する力だ。何を言えば動くかではなく、どんな条件で、どの機能が、どの責務として動くべきかを定義できる人が、AIを本当に使いこなす。

Laravel の Enum Binding がそうであるように、賢いシステムは何でも受け入れない。BDD がそうであるように、よい開発は内部の正しさだけで満足しない。AI Skills が示しているのは、その延長線上にある新しい原則だ。制御とは命令ではなく、ふるまいの入口を設計することである。

そしてこの原則を受け入れた瞬間、AIは単なる会話相手ではなくなる。仕事の流れに適切に接続され、必要なときにだけ正しく起動する、設計可能な部品になる。そこではじめて、私たちはAIに何を言うかではなく、AIがどの世界に属するかを考えるようになるのだ。