前回の記事「光と、壁」では、AIと“フル開発”を進めるときの手応え（光）と、その先に立ちはだかる限界（壁）について書きました。今回はその続編として、壁の正体にもう一歩踏み込みます。きっかけは二つ。最上位モデル Fable 5 の登場と、作業がセッションの制限で途中で止まった、ある一件でした。
Mythos 相当の Fable 5 に、使うモデルを上げてみようとした
Fable 5 は2026年6月に公開された、Claude シリーズで現時点もっとも高性能な一般公開モデルです。これまで一部の組織にのみ限定提供されていた最上位ティア「Mythos」相当の能力を、独立した安全機構を組み込むことで初めて一般公開した、という位置づけになっています。Opus 4.8 の上位にあたり、数時間〜数日に及ぶ長時間・複雑なタスクや、自律的に動くエージェント運用での強さがうたわれています。
「それなら使うモデルを上げてみよう」と切り替えようとしたところ、画面にはこう表示されました。
「This model isn’t available right now. You can switch to another model to continue using Claude.（このモデルは現在利用できません。別のモデルに切り替えれば、引き続き Claude を使えます）」
公開直後はこうした一時的な制限が出ることがあります。拍子抜けすると同時に、ふと立ち止まって考えました。自分は前評判で“過剰な期待”をしていないか、と。
モデルが強ければ、勝手に良い結果が出るわけではない
強いモデルは、こちらの前提整理の甘さまで吸収してくれる魔法ではありません。むしろ前提――指示・ルール・文脈――が難解だったり量が多すぎたりすると、強いモデルほど「全部こなそう」として、かえって挙動がぶれることがあります。
だからこそ、「いちばん賢いモデルを選べば自動的に最適」とは限りません。目的に合わせてモデルを選ぶ行為そのものが、設計の一部です。これは人に仕事をお願いするときと、やる方向性は同じで、前提を整え、ゴールを共有し、節目で確認する。相手がAIでも、変わりません。
効いたのは「小さく、絞る」― 特化スキルという解
AIに渡す作業ルール集（いわゆる「スキル」）を整備したところ、作業が目に見えて安定して進むようになりました。なかでもいちばん効果的だった改善は、一つのファイルサイズを小さく抑えることでした。
これは、スキルそのものにも効きます。サイズが大きすぎるスキルは“熟読”されず、結果としてルールが守られないことが多々発生します。実際、肥大化したルール集は分割しました。改訂履歴や補足を別ファイルへ外出しし、領域ごとに小さなスキルへ割り直したところ、読み込みが軽くなり、ルール遵守が安定しました。
見落とされがちですが、ここがいちばんの肝です。最初に投入するルールが鋭く研がれていれば、出力は驚くほど高い水準に届きます。逆に、あれもこれもと多量のルールを詰め込むと、出力はぼんやりと平均化し、よくできた検索ツール程度の答えしか返ってこなくなります。いろいろやらせすぎると、かえって性能は出ないのです。つまり、たどり着く到達点（最適点）は、最初に与えるルールベースの鋭さで決まります。最適点はあらかじめ一つに定まっているのではなく、出発点しだいで高くも低くもなる。だから、ルールを増やして細かく縛れば堅牢になる、とは限りません。むしろルールが増えるほど、それを破る挙動が多発します。
コーディングでも同じ傾向があります。ファイルが大きいと読み直しが増え、似た字形・同音語の取り違え（文字化けに近い誤り）も起きやすく、無駄な処理コストにつながります。小さく保つと、ここが目に見えて減ります。
そして気づいたのは、特定の領域に特化して小さく組み上げたスキルは、汎用に大きく書いたものより高い性能を引き出せる、という感触です。「広く曖昧」より「狭く明確」。賢さの絶対値より、前提の整え方のほうが効くのです。
「すごいのはモデル」なのか ― 増幅されるのは“問いの鋭さ”
この見立ては、いま話題のセキュリティAIにも当てはまると感じています。Anthropic は、一般公開していない最上位モデル「Claude Mythos」を限定パートナーと運用する取り組み（Project Glasswing）の初期結果として、約1か月で1万件を超える高・重大度の脆弱性を特定したと公表しました（出典：Anthropic「Project Glasswing」）。英国の公的機関 AI Security Institute（AISI）の独立評価でも、隔離された検証環境で同モデルが脆弱性を自律的に発見・悪用し、32段階の侵入シミュレーションを完了できたと報告されています（出典：AI Security Institute の評価）。
数字だけ見ると「モデルがすごい」と思ってしまいます。けれど見方を変えると、すごいのはモデル単体ではなく、そこに鋭い問いと手順を与えた、目を磨き上げたエンジニアのセキュリティスキルのほうではないでしょうか。モデルは増幅器のようなもので、鋭い問いを入れれば鋭く、鈍い問いを入れれば鈍く増幅します。脆弱性をあれだけ掘り当てられたのは、勘所を絞り込んだ“特化した問い”があったからこそ、とも読めます。先ほどの「小さく、絞る」話と、根は同じです。
そして、その鋭い目を持つハイスキルエンジニアは、そう簡単には育てられません。モデルは誰でも同じものを使えます。差がつくのは、何を・どう問うか、どんなルールベースから出発するか――つまり人側の技能です。ここを育て続けられるかどうかが、これからの企業の生き残りを分けるポイントになるのかもしれません。
「現在位置の再構築」― 変だと思ったら立ち止まる
運用を続けるうちに、時々、スキルから外れた作業が行われることに気づきました。そうした挙動を見つけたら「スキルをもう一度確認して」と促す。それだけで、たいていは元に戻ります。
これを繰り返すうちに、その現象が起きるときにはパターンがあるとわかってきました。挙動が乱れやすいのは、次のようなときです。
- 作業の途中で、セッションの制限により処理が止まったあと
- 使うモデルを切り替えたあと
- 提供側（Anthropic）のアップグレードが行われたあと
- 前回の作業から、長い時間が空いたあと
共通点は、「現在位置」――いまどの前提・どの文脈の上で作業しているのか――の連続性が切れる瞬間だ、ということです。だから再開時には、“いまどこにいるのか”をもう一度組み直す必要がある。私はこれを現在位置の再構築と呼んでいます。今回いちばんお伝えしたかったのが、この一点です。
対処そのものはシンプルです。変だと思ったら、いったん止めて確認させる。これがいちばん効きます。そして、モデルの切り替えのように意図的に制御できるものは、注意すれば最初から避けられます。
少しメタな余談を。この記事自体、前回ぶんの作業がセッション制限で途中停止していました。再開のとき私たちがまずやったのは、本文を書き始めることではなく、“どこまで進んでいたか”の確認と、“前提（方針・公開先・書き方のルール）”の再確認でした。それはまさに、ここで言う現在位置の再構築そのものでした。
まとめ ― 壁は「賢さ」では越えられない
「光と、壁」の続きとして見えてきたのは、壁はモデルをいちばん賢いものに上げれば消える、という種類のものではない、ということでした。鍵は、モデルの賢さそのものより、鋭く絞った問いを設計できる人側の技能にあります。出発点となるルールを小さく整え、特化したスキルを用意し、節目ごとに現在位置を組み直す。この地道な運用こそが、人とAIの共同開発を安定させます。
最適点は一つに決まってはいません。だからこそ、出発点を選び、確かめ、そして立ち止まる余地を残しておく。Fable 5 が使える日が来ても、たぶんこの原則は変わらないはずです。