Codex CLIが220行で打ち切る真の原因 ― プロンプト設計の盲点が引き起こす制限

AIコーディングツールを使っていると、時に予想外の挙動に遭遇します。特に、出力が特定の長さで打ち切られる現象は多くの開発者が経験しているはずです。今回取り上げるのは、Codex CLIがSKILL.mdファイルを220行で打ち切るという事例です。

この問題は単なるバグ報告以上の価値があります。なぜなら、AI開発における「仮説の立て方」と「真因の追求」という、すべてのAIエンジニアが直面する課題を象徴的に示しているからです。

当初、この現象は「モデルが学習データから引いてきた『SKILL.mdの見慣れた長さ ≈ 200行』がキャップとして機能している」という仮説で説明されていました。これは一見、もっともらしい説明です。

大規模言語モデルは学習データのパターンを学習するため、特定のファイルタイプに「典型的な長さ」という統計的バイアスが存在することは十分にあり得ます。実際、多くのREADMEファイルやドキュメントは100〜300行程度に収まることが多く、この仮説は経験的にも納得感があります。

しかし、真の原因は全く別のところにありました。Codex CLI自身のプロンプトに「**Read only enough to follow the workflow**」という明示的な指示が含まれていたのです。

この発見は重要な教訓を示しています。openai/codexリポジトリには既にIssueが立てられており、提案パッチまで作成されているにもかかわらず、問題は放置されたままです。これは、AIツールの開発において、「既知の問題」が必ずしも「修正された問題」にならない現実を物語っています。

AIツールのデバッグにおける「層」の概念

この事例が示すのは、AIツールの挙動には複数の「層」が存在するという事実です。

1. **モデル層**：学習データやモデルアーキテクチャに由来する挙動

2. **プロンプト層**：システムプロンプトやユーザープロンプトによる制御

3. **実装層**：コード側での後処理や制限

従来のソフトウェアデバッグでは、コードを追えば原因に辿り着けました。しかしAIツールでは、モデルの内部状態は直接観察できません。そのため、多くの開発者が「モデルのせい」という仮説に飛びつきがちです。

実際には、**プロンプト層の問題である可能性が最も高い**のです。なぜなら、プロンプトは明示的な指示であり、モデルはそれに忠実に従うよう訓練されているからです。

GitHub CopilotやCursor AIとの比較

GitHub CopilotやCursor AIでは、このような「読み取り量の制限」は異なる方法で処理されています。

Codex CLIの「enough to follow the workflow」という指示は、効率性を重視した設計ですが、完全性を犠牲にしています。これは、**パフォーマンスと精度のトレードオフ**という古典的な課題が、AIツールにも存在することを示しています。

オープンソースAIツールの課題

この問題がパッチ提案後も放置されている事実は、オープンソースAIプロジェクトの維持管理における課題を浮き彫りにしています。

これは、商用AIツールとオープンソースAIツールの選択において、**サポート体制とアップデート頻度を重視すべき**理由の一つです。

1. プロンプトを確認する習慣をつける

AIツールで予期しない挙動に遭遇したら、まずシステムプロンプトを確認しましょう。多くのCLIツールでは、`--verbose`フラグや設定ファイルでプロンプトの内容を確認できます。

# Codex CLIの場合（例）
codex --show-prompt

2. 仮説を層別に立てる

問題に直面したら、以下の順序で仮説を立てて検証します：

1. **実装層**：トークン数制限、API制限などのハードリミット

2. **プロンプト層**：システムプロンプトやユーザープロンプトの指示

3. **モデル層**：学習データのバイアスやモデルの特性

モデル層から疑うのではなく、観察・検証しやすい層から順に調査することで、効率的に真因に辿り着けます。

3. コミュニティの既知問題を活用する

GitHub Issuesやディスカッションを検索する習慣をつけましょう。多くの場合、あなたが遭遇した問題は既に報告されており、ワークアラウンドや解決策が共有されています。

検索キーワード例：
- "codex cli truncate"
- "skill.md line limit"
- "read only enough to follow"

この事例は、AIツールを使いこなすには従来のデバッグスキルに加えて、**プロンプトエンジニアリングの視点**が不可欠であることを示しています。

「モデルが賢くなれば問題は解決する」という期待は、半分しか正しくありません。真の解決には、プロンプト設計、実装レベルの制御、そしてコミュニティとの協働が必要です。

あなたが次に予期しない挙動に遭遇したとき、この「層別デバッグ」のアプローチを思い出してください。それが、AI時代の問題解決力を高める第一歩です。

この情報は @Haru さんの投稿を参考にしています。