AIに命令するな、概念で会話しろ: モデル切り替え時代の最強プロンプト設計

May 08, 2026

1 min read

3 views

84%

「共通化して」で伝わらないのに、「DRYで」と言うと伝わるのはなぜか

AIに仕事を頼むとき、なぜか人間に頼むより言葉の選び方が重要になる。しかも不思議なことに、細かく説明すればするほど賢くなるわけでもない。むしろ、ひとつの原則名を投げるだけで、複雑な意図が一気に通ることがある。

たとえば「ここ、共通化しといて」と言うより、「DRY原則に従ってリファクタリングして」のほうが、AIにはずっと解像度高く伝わる。これは単なる言い換えではない。前者は作業の断片を伝えているが、後者は判断の基準そのものを渡している。

そしてここに、AI時代の開発の本質がある。私たちはAIにタスクを分解して渡すだけでなく、判断のレンズを渡す必要があるのだ。

AIとの対話で本当に重要なのは、何をするかではなく、どの原則で考えるかを指定することだ。

この発想をさらに押し広げると、モデルの使い分けにも同じ原理が見えてくる。強いモデルを常に呼ぶのではなく、場面ごとに異なる認知能力を切り替える。つまり、AI時代の上手な使い方とは、単に便利な道具を使うことではなく、言葉とモデルをどう配置するかという設計にある。

便利さの本質は、速さではなく「認知の圧縮」にある

AI活用がうまくいく人は、しばしば「速い人」だと思われる。しかし本当に起きているのは速度向上ではない。認知の圧縮である。

人間が毎回ゼロから説明しなくて済むように、AIに対しては「この状況では何を重視すべきか」を短いフレーズで渡す。DRY、KISS、SOLIDのような用語は、単なるソフトウェア工学の標語ではない。AIにとっては、膨大な学習経験が凝縮された概念パッケージだ。

たとえば、次の二つの依頼を比べてみよう。

「このコード、重複をなくして、責務を分けて、読みやすくして」
「DRYとSOLIDを意識して整理して」

前者は正しいが、毎回説明コストが高い。後者は短いのに、AIの内部では「重複の排除」「責務分離」「依存関係の整理」「変更容易性の確保」といった意味の束が一度に立ち上がる。

ここで重要なのは、原則名が魔法の言葉なのではなく、原則名が思考の圧縮フォーマットとして機能していることだ。人間がよくやる失敗は、AIに対して「作業指示」ばかり与え、「評価基準」を与えないことにある。評価基準がないと、AIはもっともらしい出力を作れても、どこへ向かうべきかが定まらない。

つまり、プロンプトは命令文ではなく、思考のルールブックとして扱うほうが強い。

では、なぜモデルを切り替える必要があるのか

ここで第二の論点が出てくる。もし原則名でAIにうまく伝わるなら、万能の強いモデルを一つ使い続ければいいのではないか。だが実務ではそう単純ではない。

AIには、それぞれ得意な知的姿勢がある。あるモデルは、ざっくりした方向付けや高速な試行錯誤が得意だ。別のモデルは、複雑な制約を保ったまま整合性を詰めるのが得意だ。さらに別のモデルは、コードベース全体の文脈を踏まえた慎重な修正に強い。

ここで効いてくるのが、モデル切り替えをスレッド内で自然に行える運用だ。ひとつの会話の中で、アイデア出しは軽快なモデル、精密な修正は重厚なモデル、最終確認は別のモデル、といった具合に役割分担させると、AIは「一人の天才」ではなく、複数の専門家を束ねたチームとして機能し始める。

この構造は、開発現場での役割分担に似ている。設計者、実装者、レビュー担当、テスターがそれぞれ異なる視点を持つように、モデルにも認知スタイルの差がある。優れた運用とは、最強の一体型を探すことではなく、どの認知をどこで使うかを設計することだ。

AI活用の成熟度は、単一モデルの性能ではなく、複数モデルをどう協調させるかで決まる。

この視点に立つと、原則名の使用とモデル切り替えは別々の話ではない。むしろ同じ問題の両面だ。原則名は、AIに渡す判断軸を圧縮する技術。モデル切り替えは、その判断を処理する認知エンジンを選ぶ技術。前者が入力の設計、後者が処理系の設計である。

AI時代の本当のスキルは、指示ではなく「認知のオーケストレーション」

ここで少し視点を上げたい。多くの人は、AIにどう頼むかを「うまいプロンプトを書く技術」だと考える。だが本質はもっと大きい。必要なのは、認知のオーケストレーションだ。

オーケストラでは、すべての楽器が同じ音量で鳴るわけではない。弦が主旋律を担い、管が色を付け、打楽器が推進力を与える。AI活用も同じで、すべてを一つのモデルにやらせるのではなく、役割ごとに得意な認知を当てることが重要になる。

このとき、原則名は楽譜の記号に近い。単に「速く弾け」ではなく、「ここはレガート」「ここはスタッカート」と指示することで、演奏全体の意味が立ち上がる。AIに対しても、「バグを直して」より「KISSを優先して、変更点を最小化しつつ、責務分離も守って」のように、複数の原則を束ねた形で渡すと、出力の質が変わる。

ただし、ここには落とし穴がある。原則は強いが、増やしすぎると逆に混乱する。DRYとKISSとSOLIDを同時に唱えれば必ず良くなるわけではない。時には、今の局面で最重要な原則はひとつだけだ。

たとえば、巨大な関数を扱う場面では、まずKISSを優先して単純化する。その後、似た処理が散らばっているならDRYを使う。構造全体の保守性が問題ならSOLIDで再設計する。この順番を間違えると、AIは「賢いが過剰なリファクタリング」をしがちだ。

つまり、原則はチェックリストではなく、優先順位を付けるためのレバーとして使うべきだ。これが理解できると、AIへの依頼は「やることの列挙」から「考え方の誘導」へ変わる。

実践のコツは、原則名とモデルを対にして使うこと

ここからは具体的に考えよう。AI開発が上手いチームほど、実はタスクを細かく説明していない。その代わり、抽象度の異なる指示を階層的に使い分けている。

一番上には目的がある。たとえば「この機能は将来の改修に強くしたい」。次に方針がある。「責務を分離し、テストしやすくしたい」。その下に原則名がある。「SOLIDを意識する」。最後に実作業がある。「このクラスを分割し、依存を注入して、テストを追加する」。

この階層を使うと、AIはただの自動補完ではなく、方針に従って実装する準専門家になる。しかも、途中でモデルを切り替えられると、各層を別の強みで処理できる。

例えば、こんな運用が考えられる。

発散フェーズ: 軽快なモデルで設計案を3つ出す
収束フェーズ: 強いモデルで最小変更案に絞る
実装フェーズ: コード編集に強いモデルで具体化する
検証フェーズ: 別モデルでレビュー観点を当てる

この流れの中で、原則名は各フェーズの共通言語になる。設計案の比較でも、実装の妥当性確認でも、「これはKISS寄りか」「ここはDRYを壊していないか」といった判断がしやすくなる。

原則名は、AIに対する短い命令ではない。チーム全体の判断基準を揃えるための共有語彙である。

こう考えると、AI活用は個人のプロンプト技巧ではなく、認知と判断のインターフェース設計だとわかる。人間が曖昧に感じていた「いい感じにやって」は、AIには曖昧すぎる。だが「DRYで」「KISSで」「SOLIDで」という言葉は、曖昧な願望を実行可能な基準へ変える。

Key Takeaways

原則名を使うときは、作業ではなく判断基準を渡していると考える 「共通化して」ではなく、「DRYで」と言うと伝わりやすいのは、AIが方針を読み取れるから。
AI活用の本質は速度ではなく認知の圧縮 短い言葉で複雑な意図を渡せるほど、説明コストが下がり、出力のぶれも減る。
万能モデルを探すより、役割に応じてモデルを切り替える 発散、収束、実装、検証で適した認知は違う。ひとつの会話内で切り替える運用が強い。
原則はチェックリストではなく優先順位づけの道具 DRY、KISS、SOLIDを同時に適用するのではなく、今いちばん重要な基準を選ぶ。
AIに頼む力は、指示文の上手さではなく、認知のオーケストレーション力 目的、方針、原則、実装を階層化して伝えることで、AIはただの生成機ではなくなる。