ClaudeCodeになぜ任せっきりができないのか

現状無理な話と、絶対に無理な話

現状無理な話

まずこちらは無限の計算資源/時間があれば、解決するかもしれない話(まあけど直近解決するとは思えない、ミリしらだが、AttentionのO(N^2)の問題を解決できない間は無理なのでは、という)

コンテキストウィンドウ、狭すぎ

例えば、現時点(2025/09/06)でフロンティアモデルのClaude4.1 Opusですら、コンテキスウィンドウが20万しかない。 一見大きいように見えるが、1行10トークンほどの場合、全部ぶち込んでも2万行程度であり、in/outや過去の会話コンテキストを送ることも考えられると、コードを実際に渡せるのは1万行にも満たないだろう。 すると、途中で認知症が起こる。 具体的に言うと、

  • APIの仕様書を渡していても内容をガン無視して作り始める
  • コンテキストロストした所を、勝手に推論して埋めてしまう(結果、ハルシネーションする)
  • 設計方針のコンテキストを徐々にロストし始める、最終的には全く方針と異なる書き方、構造をしてしまう
  • 重複したコードを生産しまくる

でかいリファクタリングはできない

これが顕著だなと思ったのだが、1万行程度のフロントのコードに対してClaude Codeにリファクタリングするように命じたのだが、上手くいかなかった。

指示としてはドライの原則に基づいて、重複している処理を切り出し、可能ならコンポーネント化しろと言う話だった。 ある程度切り出してくれた後、ビルドエラーが出まくり、結果そのコンポーネントを使うのを何故かAIは辞めた。 その後、使っていないコード群、ファイルを削除しよと同会話で続けたところ、作成したコンポーネントを全てreadし直した後、使われてませんねとか言って全部消した。

まあこれは極端な例であるが、ロングコンテキストになる程、一貫性が失われ、直近の行動だけにフォーカスするようになってしまうため、自分で穴を掘った挙句何故掘ったのかを忘れ、埋めるみたいな行動をとる。

https://arxiv.org/abs/2307.03172?utm_source

逆に2000行位のバックエンド(単一ファイル)のコードは、リファクタリングに成功した。

ポチョムキン理解起きまくり

概念を正確に説明できる。 しかし、その概念を実践できない。 さらに、自分の実践が間違っていることを正しく認識できる。

https://xenospectrum.com/what-is-potemkin-understanding-the-decisive-weakness-of-llm-exposed-by-harvard-university-and-others

コードの生成の時も同様のことが起きており、例えばユーザーのクレジット処理を作る際、機能用件を話すとトランザクション処理が必要なことは理解しているのに、いざ書かせるとできてない、みたいなことが頻発する。 そして、別コンテキストでそのコードを見せると、見事に指摘できる、みたいなのが発生している。

絶対に無理な話

これはこれらの現象が無限の計算資源や数学で修正されても、残る問題。

XY問題が絶対に起きる

例えば “pythonで”hello,world”とかえすhttpサーバーを立てて欲しい” という話をしても、様々なコンテキストを勝手に補完する事になる。

  • pythonのバージョン(3.11なのか？3.12なのか？など)
  • 使うライブラリ(http.serverを使うのか、flaskを使うのか)
  • リクエストは何を受け付けるのか(get?)
  • ポートは何番を使うのか(80?8080?)
  • Content-Typeは何を返すのか？
  • 拡張する予定があるのか？(そこはハードコードしていいのか、抽象化した方がいいのか？)

この内容だけでも100種類上の分岐があると思う。

ここでClaudeに聞いてみよう

「PythonでHello WorldとかえすHTTPサーバーを立てて」と言われた際に、私が暗黙的に補完するコンテキストは以下のようなものです：

## 基本的な前提
- **目的**: 学習用・テスト用の簡単なサーバー
- **Pythonバージョン**: Python 3.x（現在主流のバージョン）
- **実行環境**: ローカル開発環境での動作を想定

## 技術的な選択
- **ライブラリ**: 標準ライブラリの`http.server`を使用（外部依存なし）
- **ポート番号**: 8000番や8080番などの一般的な開発用ポート
- **HTTPメソッド**: GETリクエストへの対応を優先
- **レスポンス形式**: プレーンテキストまたはシンプルなHTML

## コードの特性
- **シンプルさ優先**: 最小限のコードで動作する実装
- **エラーハンドリング**: 基本的なものに留める
- **セキュリティ**: 本番環境での使用は想定しない
- **拡張性**: 後から機能追加しやすい基本構造

## 実行方法
- コマンドラインから直接実行可能
- Ctrl+Cで停止可能
- 起動時にURLを表示

これらの暗黙の前提に基づいて、最もシンプルで理解しやすいコードを提供することを想定します。もし特定の要件（Flask使用、特定のポート、JSON対応など）があれば、それに応じて調整します。

で、これらの機能用件は、最終的にユーザーの脳の潜在空間を読み取れない限り不明なため、無理である。(聞き返す事で解決できるが、これに対して正確に答えられる/意思決定ができるなら、それはもうエンジニアだろう)

人間でもこれは難しいからPMなどといったマルチモーダルな推論機が用意されている訳で、テキストデータしかアクセスできない現状をスケールさせても解決しないだろう。

これらを理解していないとどうなるのか？

エンジニアじゃない皆様(馬鹿でか主語)からエンジニアはもういらない、みたいな声をたまに聞くが、まあ多分そもそもAIが意味のない穴を掘って埋めてるのに気づいてないんだと思うが、そこそこデカいプロジェクトをやろうとすると、ある時点(モデルのmaxコンテキストをプロジェクトが超えた時)から急に何も進まなくなると思う。(AIに完全ぶん投げした場合の話)

エンジニアのこれから

まずこの話をする前に、エンジニアとは何なのか、と言う話をしたい。 エンジニアとは、物事を論理分解し、新たな推論をする職業 言うなれば、演繹と帰納を行うのが本質で、AWSの仕様を覚えたり、特定の言語の文法を覚えているのは本質ではないと思う。

まあというかそこら辺のかなり意味のないKV暗記に近い部分は今後AIに代替されていく/もうされていると思っていて、結果的に直近数年は上記のAIができない部分を担当する事になるんじゃないかなと。その点では少し上流過程によるみたいな見方はできるだろう。 コードを書くのはAIだが、考え、責任を取るのは人間になるんだと思う。

一覧へ戻る