文字列で返す関数を書いてAIコーディングツールにこう指示したとき、返ってくる実装は環境や文脈によってまちまちです。C++なら char* かもしれないし、std::string かもしれない。どちらも「文字列を返す」という指示には合致していますが、用途によって正解はまったく異なります。
では、こう伝えたらどうでしょうか。
「JSONレスポンスとして文字列で返す関数を書いて」
こう言われれば、動的にサイズが変わるJSONを扱うのだから std::string だな、と推論できます。人間でもAIでも同じことです。「何を作るか」だけでなく「なぜ必要なのか」が分かると、設計判断の精度は自然と上がります。
意図が見えない作業は、人間でも混乱する
これはAI特有の問題ではありません。意図が伝わらない作業は、人間にとっても苦痛であり、品質が下がる原因になります。
極端な例ですが、「穴を掘れ」「次は埋めろ」を繰り返させる行為は、古くから拷問の一形態として知られています。作業そのものの負荷ではなく、目的が分からないことによる精神的な消耗が本質です。ソフトウェア開発でも「仕様書に書いてあるとおり作った」のに要求と異なるものが出来上がる、という経験は珍しくありません。仕様書にはHowが書かれていても、Whyが欠落していることが多いからです。
目的が分からなければ、人間は機械的に手を動かすだけになり、作業の質は下がります。AIもまったく同じです。指示どおりに動くことと、意図を理解して動くことの間には、埋めがたい品質の差があります。
「なぜ」がわかると、設計レベルが変わる
この差は、型にストイックな言語を使うほど顕著になります。
先ほどの「文字列で返す」の例で言えば、C++では char*（生ポインタ）、std::string（標準ライブラリの文字列型）、std::string_view（参照のみの軽量型）など、選択肢が複数あります。「何に使われるのか」が分かれば、メモリ管理の方針、ライフタイムの考慮、パフォーマンス特性を踏まえた選択を自ずと推論できます。
これはAIコーディングにおいても同じです。むしろ、LLMは膨大なコードベースから学習しているぶん、「この用途ならこの型が一般的」というパターンマッチが得意です。ただし、用途を知らなければそのパターンマッチは発動しません。
設計意図を伝えることは、AIの推論能力を引き出すトリガーなのです。
実験で見えた、意図がもたらす具体的な違い
では、設計意図を記録・参照できる環境は、実際にどれほどの違いを生むのでしょうか。
私たちは、TypeScriptによるワークフロー承認システムの開発を題材に、12の指示からなる対照実験を行いました。
- 設計意図をsqlewで記録・参照する条件
- 設計意図なしの条件
で、同一のタスクを実行し比較しています。
開発時間：最大22.4%の削減
全体の比較で、設計意図を与えた場合は398分、設計意図がない場合は513分。22.4%の開発時間削減を達成しました。しかもこの差は均等ではなく、設計意図が有効に作用する機能追加やアーキテクチャ変更のタスクでは50%以上削減できたケースもありました。全体を通じて、約8割のタスクで設計意図を与えた側が高速に完了しています。
興味深いのは、この差がプロジェクト序盤ではなく後半に加速的に拡大していくことです。最初の数タスクでは、設計意図の記録にかかるオーバーヘッドでやや不利に見える場面もあります。しかしプロジェクトが複雑になるにつれて、過去の設計判断を参照できる側の優位が一気に広がっていきました。
AIの「考え方」が変わる
数値以上に示唆的だったのが、AIの推論パターンの質的な変化です。
設計意図がない場合、AIは「書いてみる→失敗する→修正する」という試行錯誤ループに陥りがちでした。一方、設計意図を与えた場合は「過去の方針を参照する→衝突を予測する→回避して実装する」という文脈に基づく推論パターンが観察されました。
この差は「過去の設計判断への参照頻度」にも如実に表れています。AIの思考過程を分析すると、過去の方針を参照するキーワードの出現密度が、序盤こそ+21%の差でしたが、中盤で+64%、終盤には+137%と加速度的に開いていきました。設計意図の記録が蓄積されるほど、AIは新しい判断にそれらを活用するようになる。正のフィードバックループが形成されていたのです。
「何をすべきか」という指示だけではAIの行動は安定しません。「なぜそうすべきか」という根拠を渡すことで、AIの推論パターンそのものが変わる。この実験を通じて得られた知見は、AIコーディングにおける設計意図の伝達がいかに重要かを物語っています。
意図を記録する習慣を、AIが実用的にする
設計意図を記録する重要性は、2011年にMichael Nygardが提唱したADR（Architecture Decision Record）の時代から認識されていました。しかし、人間にとっての記録コストが高く、継続運用は難しいとされてきました。
AIコーディングツールの普及が、この前提を変えつつあります。設計判断の記録を自動化し、必要なタイミングで必要な文脈だけをAIに渡す。sqlewはこの仕組みをMCP経由で実現するツールです。
「何を作るか」だけでなく「なぜ作るのか」を伝える。たったそれだけのことが、AIの推論パターンを変え、開発効率と品質の両方を押し上げる。実験データはそれを裏付けています。
参考文献
- "Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation" — Shingo Kitayama (2026) — sqlew Efficacy Study
- "LLMs Get Lost In Multi-Turn Conversation" — Bao et al. (2025) — arXiv:2505.06120
- "Context Length Alone Hurts LLM Performance Despite Perfect Retrieval" — ACL Findings (EMNLP 2025) arXiv:2510.05381
