LLMに必要なのは高性能化ではなく、注意力の設計だ

Apr 30, 2026

1 min read

3 views

88%

いつも失敗するのは、賢さではなく「注意の散漫」だった

AIがコードをうまく直せないとき、多くの人はまず能力不足を疑います。モデルがまだ弱いのか、文脈理解が足りないのか、長いコードベースには向いていないのか。けれど、実際に起きていることはもっと根本的です。問題の中心は、LLMの知能そのものではなく、注意力がどこに向くかという設計にあります。

ここでいう注意力は、単なる「集中」の比喩ではありません。モデルは与えられたコンテキストの中で、どの情報を優先し、どの情報を捨て、どの粒度で作業するかによって、出力の質が大きく変わります。つまり、同じモデルでも、注意の向け先を設計できるかどうかで、まるで別の道具になるのです。

この視点に立つと、コード編集の操作は単なる便利機能ではなくなります。局所的なクリーンアップをするのか、複数ファイルにまたがる変更をするのか、あるいはまず作業範囲を狭めるのか。これらはすべて、AIに「何を見せ、何を見せないか」を決めるための、注意力の制御装置です。

LLMは万能なプログラマーではなく、文脈に反応する作業者である

人間のエンジニアは、長いコードベースを見ても、頭の中で自然に層を分けます。今は関数単位で考えるのか、モジュール単位で考えるのか、設計全体を見直すのか。視点の切り替えができるからこそ、局所最適と全体最適を行き来できます。

LLMにもそれに似た働きはありますが、同じやり方ではありません。LLMは「頭の中で勝手に視点を整理している」のではなく、与えられた情報の密度と範囲に強く影響されます。だからこそ、コードベース全体を一気に見せると、関連性の低い情報まで同時に響いてしまい、注意が分散します。

この分散は、能力の低さではなく、構造の問題です。人間でいえば、会議室に10人入れて1人だけに話しかけたいのに、全員が同時に発言している状態に近い。聞こえてはいるが、どれを優先すべきかが曖昧になり、結果として雑な修正になりやすいのです。

ここで重要なのは、LLMを「知識の倉庫」として扱う発想から離れることです。むしろ、注意を配線する対象として見るべきです。優れたプロンプトやスキル設計とは、正しい答えを教えることではなく、正しい注意の流れを作ることなのです。

AIの失敗は、しばしば「知らない」からではなく、「見すぎている」から起こる。

この逆説を理解すると、編集の戦略が変わります。単にもっと情報を渡すのではなく、必要な情報だけを、必要な順番で、必要な粒度で渡すことが、成果を左右するようになります。

/simplify と /batch は、編集の大小ではなく「認知のモード」が違う

一見すると、/simplify と /batch の違いは、単に小さな修正か大きな修正かの違いに見えます。けれど本質はそこではありません。両者は、AIに求める認知モードが違うのです。

/simplify が向いているのは、実装後の局所的なクリーンアップです。命名の整理、冗長な条件分岐の削除、細部の整形、つまりすでにある構造を滑らかにする仕事です。このとき必要なのは、広い視野よりも、近傍の整合性です。AIに求めるのは、全体設計の再構築ではなく、局所のノイズ除去です。

一方で /batch は、フレームワーク移行やコードベース横断の変更に向いています。複数ファイル、複数責務、複数の依存関係が絡むような場面では、単発の修正ではなく、変更を一括で束ねる必要がある。ここでは、個々の局所修正の正しさより、移行の一貫性が重要になります。

この違いを単純化すると、/simplify は「レンズを磨く」操作で、/batch は「地図を描き直す」操作です。レンズ磨きに地図は要りませんし、地図の描き直しにレンズ磨きだけでは足りません。両者の違いを誤ると、AIに小手先の修正をさせたいのに大域的な混乱を招いたり、逆に大きな移行が必要なのに細部の微調整に終始したりします。

ここで見えてくるのは、優れたAI活用とは、タスクを分割する技術である、ということです。人間は「何を頼むか」を考えがちですが、本当に難しいのは、どの認知モードで頼むかを選ぶことです。

仕事を速くする鍵は、AIを賢くすることではなく、仕事を層に分けること

この話をさらに深くすると、コード編集の問題は、実は知能の問題ではなく層の設計の問題だとわかります。複雑な作業は、常に異なるスケールの課題が混ざっています。たとえば次のような層です。

局所層: 変数名、関数分割、軽いリファクタリング
構造層: ファイル間の依存、責務の整理、APIの整合性
移行層: フレームワーク変更、仕様変更、横断的な置換
意図層: なぜこの変更をするのか、何を壊してはいけないのか

多くの失敗は、これらの層を同時に扱おうとすることから起こります。たとえば、本当は局所層の作業なのに、AIが構造層や意図層まで勝手に解釈し始めると、無関係な修正が混ざります。逆に移行層の仕事なのに局所層の感覚だけで進めると、表面だけ合っていて整合性が崩れます。

だからこそ、AIに与える最適な指示は「何をしてほしいか」だけでなく、「いまどの層だけに集中してほしいか」です。これは人間のマネジメントにも似ています。優秀なチームほど、会議で全てを一度に決めません。仕様、実装、運用、意思決定の層を分け、それぞれに適した時間と議題を設定します。

LLMへの指示も同じです。局所の整形をするときは、世界全体の設計を持ち込まない。全体移行をするときは、細部の美しさに引きずられない。作業の失敗は、しばしば粒度の誤配分として現れます。

良い自動化とは、すべてを一気にやることではない。必要な粒度だけを見える化することだ。

この視点は、単なるプロンプト術を超えています。作業の分割そのものを、注意の流れを制御する設計として捉え直しているからです。

本当に必要なのは「プロンプト」ではなく「注意のルーティング」

多くの人はAIに命令するとき、文章の上手さを磨こうとします。しかし、実際に効くのは文体ではなく、注意のルーティングです。どの情報を先に見せるか、どの情報を切り離すか、どこで作業を止めて確認するか。これらはすべて、モデルの注意をどこへ流すかの設計です。

たとえば、あるコード修正で次の順序を考えてみます。

まず対象ファイルを狭くする
次に関連する関数だけを見せる
最後に必要なら周辺の依存を追加する

これは、人間が段階的に考えるときの自然な流れです。しかし、LLMにはその流れを明示しないと、最初から広すぎるコンテキストを扱ってしまい、結果として焦点がぼやけます。注意を段階的に流すことで、AIは「いま何を判断すべきか」を理解しやすくなるのです。

この考え方は、単なる性能改善よりも重要です。性能を上げることには上限がありますが、注意の設計にはまだ大きな伸びしろがあります。なぜなら、多くの失敗はモデルの限界ではなく、問題設定の粒度に由来するからです。

ここで人間側の役割も変わります。私たちはAIに答えを求めるのではなく、AIが最も力を発揮できる「問いの形」を与える必要があります。問いの形とは、範囲、順序、粒度、そして禁止事項です。これが整うと、同じモデルでも驚くほど安定します。

たとえるなら、優秀な料理人に最高級の食材を渡しても、調理台が散らかっていれば料理は乱れます。必要なのは食材の追加ではなく、切る順番、火加減、置き場所の設計です。AIも同じで、答えを増やすより、注意の置き場所を整えるほうが効くのです。

Key Takeaways

AIの失敗は能力不足ではなく、注意の分散として捉える
- まず「何が足りないか」ではなく、「何に気を取られすぎているか」を考える。
局所修正と横断的変更は、まったく別の認知モード
- /simplify は局所の整形、/batch は大域の移行や一括変更、と意識して使い分ける。
タスクを層に分けることで、AIの注意を安定させる
- 局所層、構造層、移行層、意図層を混ぜない。
プロンプトを磨くより、情報の順番を設計する
- 先に狭く、あとで広げる。いきなり全体を見せない。
「どれだけ賢いか」より「どれだけ集中できるか」が成果を決める
- AI活用の競争力は、モデル選定より注意設計に宿る。

結論: AI時代の本当の熟練は、知能の外注ではなく注意の編集である

私たちはしばしば、AIに何を覚えさせるか、どれだけ賢くするかに注目します。しかし、実務で本当に差がつくのは、AIの知能ではなく、その注意をどう編集するかです。局所の雑音を消したいのか、大域的な移行を完了したいのか。それぞれに必要なのは異なる視野であり、異なる粒度であり、異なる指示の出し方です。

つまり、AIを使いこなすとは、単に強いモデルを使うことではありません。モデルの注意が最もきれいに通る作業単位を見つけることです。そこに気づいた瞬間、AIは「なんとなく便利な道具」から、「意図に沿って働く作業系」へと変わります。

そしてその変化は、私たち自身にも返ってきます。AIに注意の設計を求めることは、結局のところ、自分の仕事の切り分け方を洗練させることだからです。AIを整えることは、仕事の見方を整えることでもある。そこに、このテーマの最も深い面白さがあります。