Fable 5とGPT-5.6 Sol：1日16時間のAI開発ワークフロー

Fable 5とGPT-5.6 Solは現在、ある開発者が報告する1日16時間のコーディングルーティンの中核を担っているが、どちらのモデルにもプロジェクトの全権は与えられていない。

AIHOTを手がける開発者によると、Fable 5が大規模な実装計画を作成し、GPT-5.6 Solがそれに異議を唱え、Codexが修正された仕様を実行するという。彼は時折、結果をリモートで監視しながら、コーディングエージェントを数時間にわたって稼働させている。

この話は、Kha’Zixとして知られる中国のテクノロジーライターが7月15日に投稿した記事に基づいている。これは対照実験ではなく、個人的なワークフローを説明したものだ。その性能に関する主張は、独立した検証を受けていない。

それでも、このプロセスはAI支援型ソフトウェア開発における重要な変化を捉えている。コード生成が容易になる一方で、計画、テスト、そして結果を信頼できるかどうかの判断に、より多くの注意が必要になっている。

このワークフローは、最先端モデルに関する一般的な前提も退けている。Fable 5とGPT-5.6 Solのどちらが普遍的に優れているかを問うのではない。観察された強みに基づき、各モデルにより限定された役割を割り当てている。

Fable 5はアーキテクトとして機能する。GPT-5.6 Solは懐疑的なレビュアーとなる。Codexはファイルを編集し、テストを実行し、失敗に対応する粘り強い実行役を務める。

この役割分担は、単一のベンチマークでの勝利よりも重要だ。モデル間の意見の相違を、不便なものではなく品質管理の仕組みとして扱っている。

Fable 5とGPT-5.6 SolによるAI開発ワークフロー

報告されたワークフローでは、1つのモデルにすべての役割を担わせるのではなく、設計、批評、実行を分離している。

元の説明によると、プロセスは望ましいプロダクト変更の詳細な記述から始まる。その記述には、目標、関連ファイル、既知の制約、期待される動作が含まれる。

Fable 5が最初の主要な任務を受け取る。著者は、大規模な技術計画の初版を設計するうえで、Fable 5が特に効果的だと考えている。

その計画が直接コーディングエージェントに渡されることはない。著者はそれをGPT-5.6 Solに渡し、提案に誤りがないか調査するようOpenAIのモデルに依頼する。

報告によれば、SolはFableが見落とした重大な弱点を特定する。これには、誤った前提、欠けているエッジケース、既存のコードベースと矛盾する手順などが含まれる可能性がある。

修正された計画は、その後Fable 5に戻される。著者が仕様を実装可能な状態だと判断するまで、モデルはこのレビューサイクルを繰り返すことができる。

そこで初めて、Codexが変更を開始する。著者によると、成果をより長い一連の作業にわたって維持する、目標指向型の実行モードを使用しているという。

OpenAIは目標について、完了、一時停止、または追加情報の要求に至るまでCodexが追求する持続的な目的だと説明している。同社のガイダンスでは、その目的を設定する前に作業を計画することを推奨している。

この違いは重要だ。従来型のプロンプトは1つの回答を要求する。持続的な目標は、エージェントに成果、境界、完了の定義を与える。

著者は、あるCodexの実行が17時間続いたと主張している。この数字は個人的な経験を表すものであり、文書化された上限や一般的な実行時間ではない。

長時間の実行が、継続的な進捗を意味するわけではない。エージェントは、ファイルの読み取り、テストの実行、エラーからの復旧、効果のないアプローチの反復に時間を費やすことがある。

したがって、このワークフローはチェックポイントに依存している。開発者はテスト結果を確認し、変更されたファイルを調査し、エージェントが承認済みの計画から逸脱した場合には介入する。

この流れは、小規模なエンジニアリング組織をソフトウェア内に圧縮したようなものだ：

• Fable 5がアーキテクチャと実装経路を提案する。

• GPT-5.6 Solが敵対的な設計レビューを行う。

• 人間が意見の相違を解決し、仕様を承認する。

• Codexが承認済みの作業を実装し、検証を実行する。

• 人間が変更を受け入れる前に証拠を評価する。

これは完全に自律的なソフトウェア開発ではない。人間は、目標の選択、批評の評価、リスクの承認、結果がいつ完成したかの定義について、引き続き責任を負う。

エージェントの実行時間が長くなるほど、その責任はより重要になる。実行役の持久力が高まり、権限が広がれば、誤った前提がより多くのファイルに波及する可能性がある。

したがって、このFable 5とGPT-5.6 SolによるAI開発ワークフローで最も有用な特徴は、その実行時間ではない。権限を意図的に分離している点だ。

コード生成がもはや主要なボトルネックではない理由

コーディングエージェントが高速になるにつれ、希少な資源はキーストロークから信頼できる判断へと移行する。

従来の開発ワークフローでは、設計を構文へ変換するためにかなりの時間を費やす。開発者はファイルを作成し、インターフェースを接続し、反復的なテストを記述し、単純なコンパイラエラーを修正する。

コーディングエージェントは、こうした機械的な作業の多くを圧縮する。リポジトリを調査し、関連コンポーネントを編集し、コマンドを実行し、テスト失敗後に反復作業を行うことができる。

この高速化によって、エンジニアリング作業がなくなるわけではない。難しさが、適切な変更を指定することと、実装が正しく動作することを証明することへ移る。

AIHOTの著者は、テスト、検証、計画レビューを新たなボトルネックとして説明している。この見解は、彼のワークフローの構造と一致する。

不十分な計画からでも、もっともらしいコードは生成され得る。結果はコンパイルできても、状態、権限、障害復旧、並行処理、既存のユーザーデータを誤って扱う可能性がある。

自動テストがそのリスクを軽減できるのは、正しい動作を測定している場合に限られる。エージェントは、根本的な欠陥を残したまま、不完全なテストスイートを満たすことができる。

これにより、検証ギャップが生じる。エージェントは、人間が変更の複合的な影響を理解できる速度よりも速く変更を生成する。

長時間の実行は、そのギャップを広げる。編集が追加されるたびに、最終的な要約から再構築することが難しい依存関係が生じる可能性がある。

解決策は、単に生成テストを増やすことではない。モデルは、実装とテストの両方で同じ誤解を再現する可能性がある。

FableとSolのレビュー・ループは、実装開始前に認知的多様性を導入しようとするものだ。一方のモデルが一貫性のある計画を作成し、もう一方にはそれを攻撃する許可が与えられる。

このアプローチは、エンジニアリング設計レビューに似ている。別のレビュアーが文言を磨くのではなく、障害条件を探すことで、提案の価値は高まる。

OpenAIのGPT-5.6の発表は、より長時間のエージェント型作業への広範な移行を裏付けている。同社によると、Solはツールを連携させ、中間結果を処理し、その後のアクションを選択できる。

OpenAIはまた、コーディングエージェント評価や長時間にわたる専門的タスクでの向上を報告している。独立したベンチマークの枠組みを取り入れている場合でも、これらの数値はベンダーが公表したものだ。

Anthropicも、同様に要求の厳しい作業を中心にFable 5を位置づけている。このモデルがClaude Codeに戻ったことで、開発者は複雑なリポジトリ変更を計画・実行するための別の選択肢を得た。

実務上の負担は、開発者とエンジニアリングチームにかかる。生産性が高まり続けるエージェントに追随できる評価システムが必要だ。

これには、単体テスト以上のものが含まれる。チームには、統合テスト、現実的なフィクスチャ、セキュリティチェック、パフォーマンス測定、明確な受け入れ基準が必要だ。

また、エージェントが何を試みたかを示すログも必要になる。すべてのテストに合格したという最終メッセージだけでは、エージェントが無関係な動作を変更した場合、ほとんど役に立たない。

リポジトリの構成も、これまでとは異なる意味で重要になる。明確なドキュメント、安定したコマンド、明示的な所有権ルールは、人間とエージェント双方のための操作手順となる。

アーキテクチャ上の決定を検索できる記録も有用になる。チームは、規律あるドキュメント作成やエンジニアリング・ナレッジベースを通じて、そのコンテキストを維持できる。

競争優位の源泉は、もはや入力速度ではない。プロダクトのアイデアを、曖昧さを最小限に抑えたテスト可能な仕様へ変換する能力だ。

Fableが計画し、Solが欠陥を探す

中心となる競争はFable 5対GPT-5.6 Solではなく、単一モデルの自信対構造化された意見の相違だ。

モデル比較では通常、1つの勝者を求める。ベンチマークはモデルを順位づけし、開発者は好みのアシスタントを共有し、ベンダーは自社システムが優位に立つカテゴリーを強調する。

AIHOTのワークフローは、異なる結論に達している。モデルは、別の有能なモデルと意見が異なるからこそ価値を持ち得る。

著者は、大規模なソリューションの初版を作成する能力において、Fable 5が並外れて優れていると評価している。これは、集中的な個人利用に基づく主観的な評価だ。

優れた初期計画には、多くの意思決定にわたる一貫性が必要だ。モデルは依存関係を追跡し、実装手順の順序を決め、変更が既存システムにどう影響するかを予測しなければならない。

その能力が、信頼できる自己批判を保証するわけではない。モデルが一度あるアプローチに傾倒すると、その後のレビューでも当初の枠組みが維持される可能性がある。

このプロセスにおいて、GPT-5.6 Solは外部の批評役を務める。著者によると、SolはFableの提案に重大な問題を頻繁に見つけるという。

OpenAIは、Solを複雑な専門業務向けのフラッグシップモデルとして売り出している。同社は、コーディング、ブラウジング、コンピューター操作、長期的なエージェント評価で優れた結果を報告している。

報告されている強みを踏まえれば、レビュアーという役割には妥当性がある。ただし、発表時のベンチマークだけでは、SolがFableによって生成されたすべての計画の誤りを確実に発見できるとは証明できない。

また、Fableがアーキテクチャを永久に独占するわけでもない。開発者、リポジトリ、タスクが異なれば、優先される順序が逆になる可能性もある。

価値は役割の割り当てから生まれる。各モデルは、「これを正しく構築して」という曖昧な要求ではなく、1つの責任に最適化されたプロンプトを受け取る。

計画用プロンプトでは、前提、影響を受けるコンポーネント、移行リスク、テスト範囲、ロールバック条件を求めるべきだ。また、不確実性を明示することも要求すべきである。

レビュープロンプトは、正反対の姿勢を取るべきだ。矛盾、欠けている依存関係、セキュリティ上の懸念、誤って合格する可能性のあるテストを探す必要がある。

その後、人間が両方の出力を比較する。この手順により、レビューモデルが、もっともらしい計画の1つを、根拠のない別の好みに密かに置き換えることを防げる。

構造化された意見の相違は、有用な記録も生み出す。開発者は、どのリスクが提起され、どのリスクが受け入れられ、どのリスクが最終設計を変更したのかを確認できる。

その記録は、後に実装が失敗した際に不可欠となる。実行上のエラーと、承認済みの仕様にすでに組み込まれていた弱点を区別するのに役立つ。

このワークフローは、生成者・検証者パターンに似ている。一方のシステムが解決策の候補を生成し、もう一方が制約と潜在的な障害ケースに照らして評価する。

しかし、検証者は万能ではない。GPT-5.6 Solは、存在しない問題を作り出したり、リポジトリを誤解したり、不必要な複雑さを推奨したりする可能性がある。

同様に、Fableも、誤った前提に基づく洗練された計画を擁護する可能性がある。2つのモデルが合意しても、正しさの証明にはならない。

両者に共通する学習パターンによって、相関した誤りが生じる可能性もある。特に、そのルールが文書化されていないチーム内の知識にしか存在しない場合、両方が同じドメイン固有のルールを見落とす可能性がある。

人間によるレビューが最終的な判断層であり続けるのは、モデルが持っていない可能性のある情報を人間が保持しているからだ。これには、ビジネス上の優先事項、運用履歴、リスク許容度が含まれる。

主な教訓は、「より多くのモデルを使う」よりも限定的だ。チームは、明確に異なる役割、明確に異なるプロンプト、明確に異なる証拠基準を設けるべきである。

その構造がなければ、2つ目のモデルも自信に満ちた文章を生み出すだけの存在になりかねません。その構造があれば、意見の相違によって、前提がコードになる前に明らかになります。

Codex Goal Modeが計画を長時間実行ジョブに変える

永続的なエージェントは、実装を一連のプロンプトから、監督下の実行プロセスへと変えます。

計画がレビューを通過すると、AIHOTの作者はそれをCodexへ移します。この移行により、静的な仕様がリポジトリ上のアクションへと変換されます。

OpenAIのCodex向けガイダンスでは、望ましい成果を説明し、関連資料をエージェントに示し、境界を設定し、完了条件を定義することが重視されています。

こうした詳細によって、長時間の実行が生産性を維持できるかどうかが決まります。「機能を実装する」だけでは、あまりにも多くの判断が暗黙のまま残されます。

より良いゴールには、期待されるユーザーの挙動、変更を許可するディレクトリ、必須のチェック、禁止される変更、人間の承認が必要となる条件を明記します。

そうすればCodexは、ファイルの調査、コードの編集、コマンドの実行、テスト失敗への対応を行えます。このプロセスは、詳細な作業指示書に従う若手エンジニアに似ています。

Goal modeでは目標が持続するため、対話パターンが変わります。開発者は、メッセージのたびにコンテキスト全体を再構築することなく、追加の指示を送れます。

作者は、オフィスへ移動している間もリモートでコーディングを続けていると述べています。このシナリオは、永続的な実行がオートコンプリートやチャットと異なって感じられる理由を示しています。

ユーザーが場所を移動している間も、エージェントはリポジトリ内で作業を続けます。人間の役割は、編集を一つずつ行うことから、一連のアクションを監督することへ移ります。

OpenAIのCodexガイダンスでは、規模の大きなタスクをplanning modeで開始することを推奨しています。ゴールには、成果と完了を証明するために必要な証拠を定義すべきです。

17時間のセッションは印象的に聞こえますが、継続時間は品質の尺度ではありません。検証済みの短時間の実行のほうが、再試行に大半を費やした長時間のセッションより大きな価値をもたらす場合があります。

有用な指標には、採用された変更、リグレッション率、レビュー時間、見逃された不具合、人間によって破棄されたエージェント作業の割合などがあります。

チームは介入頻度も測定すべきです。絶え間ない修正が必要なら、ゴール、リポジトリのコンテキスト、またはタスクの境界が依然として不十分である可能性があります。

長時間稼働するエージェントには、明示的な停止条件が必要です。破壊的な操作、予期しないスキーマ変更、権限変更、失敗の繰り返しが発生した場合は、一時停止すべきです。

また、アクセスも制限する必要があります。実行役には、承認されたタスクに必要な認証情報とシステムだけを与えるべきです。

本番環境への広範なアクセス権を持つコーディングエージェントは、計画上のミスを運用インシデントへ発展させる可能性があります。永続性が高まるほど、最小権限による制御の重要性も増します。

バージョン管理は、もう一つの境界を提供します。説明的なメッセージを付けた小さなコミットにより、レビュアーは変更を段階的に確認し、限定的な失敗だけを元に戻せます。

テスト結果は、それらの変更に紐づけて保持すべきです。検証に成功したという主張には、使用したコマンド、環境、関連する出力を明示すべきです。

ユーザー向け機能では、エージェントは孤立した関数だけでなく、現実的なワークフローをテストすべきです。これには、ブラウザ操作、データ移行、中断された操作からの復旧などが含まれます。

仕様では、必須テストと任意の探索を区別すべきです。そうしなければ、エージェントは承認済みの変更を完了する代わりに、何時間もスコープの拡大に費やす可能性があります。

ここで、Fable 5とGPT-5.6 SolのAI開発ワークフローは、単なるモデル比較以上のものになります。計画の品質が、永続的な実行の有用性を直接左右するからです。

優れた実行役は、受け取った計画を増幅します。上流にある戦略的な誤りをすべて自動的に修復するわけではありません。

16時間のルーティンが示すのは熱意であり、信頼性ではない

報告されたスケジュールは熱意と利用環境を示していますが、完成したソフトウェアの妥当性を証明するものではありません。

元の投稿によると、作者はvibe codingに毎日約16時間を費やしています。深夜まで作業し、短時間眠り、リモートアクセスを通じて作業を続ける様子を説明しています。

この話が印象的な見出しを生み出しています。同時に、最も重要な注意点も浮き彫りにしています。

コーディングエージェントに費やした時間が、エンジニアリング品質へ直接つながるわけではありません。疲労によって、開発者が微妙なエラーを見つけたり、説得力のあるモデル出力に疑問を呈したりする能力が低下する可能性があります。

このルーティンは持続が困難な可能性もあります。意欲の高い一人の創業者による継続的な監視を前提としたワークフローは、より大きなチームには適用できないかもしれません。

「vibe coding」とは一般に、自然言語で指示を与えながら、AIに実装の大部分を生成させるソフトウェア開発を指します。この呼称には、技術的な監督レベルが大きく異なる手法が含まれます。

視覚的な確認だけで出力を受け入れるユーザーもいます。一方で、差分を調査し、テストスイートを設計し、パフォーマンスを測定し、生成されたすべての変更を信頼できないものとして扱うユーザーもいます。

AIHOTのプロセスは、後者に近いものです。その計画とレビューの段階には、「vibe coding」という言葉から一般に想像されるものよりも多くの構造があります。

ただし、報告された17時間の実行は、あくまで自己申告の事例です。公開された記述には、完全なタスクログ、リポジトリの差分、独立した不具合分析は含まれていません。

AIHOTのオーディエンス拡大に関する報告も同様です。作者は月間アクティブユーザーが50万人を超えたと述べていますが、独立した分析データは公開されていません。

こうした不足がワークフローを無価値にするわけではありません。読者が何を確立された証拠ではなく観察として扱うべきかを示しています。

ベンダーの主張にも同様の注意が必要です。OpenAIは、GPT-5.6 Solがエージェント型コーディングの各種評価で、多くの場合、より少ないトークンと短い時間で高い性能を示すと報告しています。

これらの測定結果は有用なシグナルですが、ベンチマークは実際のリポジトリを単純化しています。本番システムには、文書化されていない依存関係、変化する要件、組織固有のリスクがあります。

Anthropicの最近の経緯は、外部条件によってアクセスが変わり得ることも示しています。Fable 5は6月9日にリリースされた後、直ちに政府による制限を受けました。

Anthropicは、リアルタイムで国籍を確実に確認できなかったため、アクセスを停止したと説明しています。同社は、規制解除後にグローバルでの提供を再開しました。

このFable 5のタイムラインは、特定のモデルを中心に構築されたワークフローにとって重要です。利用可能性が技術的な依存関係になり得るからです。

この制限は、サイバーセキュリティ能力への懸念を受けたものでした。Anthropicは後に、性能の低いモデルでも、問題視された脆弱性の実証を再現できると述べました。

OpenAIも、一般提供に先立ち、制限付きプレビューを通じてGPT-5.6をリリースしました。Axiosの記事では、同モデルのサイバーセキュリティ能力に対する政府審査について報じています。

これらの出来事は、より広範な運用上の疑問を生み出します。推奨するプランナーやレビュアーが予告なく利用できなくなった場合、どうなるのでしょうか。

チームには代替計画が必要です。プロンプト、評価基準、設計記録は、モデルプロバイダーをまたいで移植可能な状態に保つべきです。

また、役割を変更してもワークフローが成功するかをテストすべきです。Solが計画を作成し、Fableまたは別のモデルがレビューすることもできます。

この検証により、品質が選択したモデルによるものなのか、それともそれらを取り巻く規律あるレビュー構造によるものなのかを明らかにできます。

もう一つのリスクは自動化バイアスです。特に、エージェントが多数の定型タスクを正しく完了する様子を見た後では、開発者は詳細な説明を証拠と混同することがあります。

最善の防御策は、観察可能な検証です。テスト、差分、ログ、再現可能なコマンドは、自信や雄弁さよりも重要です。

2つ目の防御策は、選択的な手動レビューです。セキュリティ境界、データ移行、請求ロジック、不可逆的な操作は、外観上の変更よりも厳密に確認する必要があります。

最後の防御策は、作業量の規律です。トークンが潤沢に利用できるように感じられても、人間の判断力は有限の資源です。

開発者が責任を持ってレビューできる量を超える作業を生成するプロセスは、安全な処理能力を超えています。

今後3か月間に開発者が注視すべきこと

このワークフローが重要な意味を持つのは、マルチモデルレビューが人間のレビュアーを圧倒することなく不具合を減らすと、継続的な証拠によって示された場合だけです。

最初のシグナルは、実際のリポジトリにおける独立したパフォーマンスデータです。公開ベンチマークは基準を確立しますが、すべての本番環境の制約を測定するものではありません。

開発者は、単一モデルとマルチモデルのワークフローを比較する対照実験を探すべきです。最も強力なテストでは、同一のタスク、リポジトリ、権限、受け入れ基準を使用します。

関連する成果指標には、完了率、不具合の深刻度、レビュー時間、後に削除された生成コードの量などがあります。

Fableによる計画とSolによるレビューの組み合わせが重大な不具合を一貫して減らすなら、AIHOTのアプローチを支持する根拠が強まります。結果が単一モデルのワークフローと同等なら、追加の段階は複雑さを増やすだけです。

2つ目のシグナルは、永続的なゴール実行中のCodexの挙動です。OpenAIは長期的な実行を重要な能力として提示していますが、最大継続時間よりも信頼性のほうが重要です。

チームは、Codexが説明を求める頻度、アプローチを放棄する頻度、失敗したコマンドを繰り返す頻度、承認されたスコープを超えて拡大する頻度を調べるべきです。

また、長時間の実行によって一貫性のあるコミットが生成されるかも追跡すべきです。成功したセッションでは、巨大な差分を一つ残すのではなく、理解可能な変更の連鎖が残るべきです。

進捗報告が改善されれば、このモデルはさらに強化されます。開発者には、完了した作業、残る不確実性、実行中に収集された証拠についての簡潔な説明が必要です。

永続的なゴールが最も有用なのは、人間が安全にその場を離れられる場合です。そのためには、予測可能な一時停止条件と、可視化された状態が必要です。

3つ目のシグナルは、プロバイダーの安定性とモデルの移植性です。Fable 5とGPT-5.6 Solはいずれも、高度なサイバーセキュリティ能力に対する異例の政府の注目を受けるなかで登場しました。

将来の制限、セーフガードの変更、使用上限、製品アップデートによって、モデルの挙動が変化する可能性があります。特定のモデルの組み合わせに強く依存したワークフローは、依然として脆弱です。

チームは、モデルに依存しない仕様と評価スイートを維持すべきです。プロセス全体を再設計することなく、プランナー、レビュアー、実行役を置き換えられるようにすべきです。

これは、組織に交渉力も与えます。タスク固有の評価によって、自社環境内で実際に最も高い性能を発揮するモデルが明らかになります。

したがって、短期的な競争はベンチマークスコアだけにとどまりません。OpenAIとAnthropicは、自社のエージェントが長時間にわたる複雑で監査可能な作業でも有用であり続けることを証明しなければなりません。

開発者は、一度のリリースサイクルだけで恒久的な勝者を選ぶべきではありません。モデルの性能は急速に変化しますが、健全な評価手法の価値は変わりません。

AIHOTの記録は、説得力のある初期パターンを示しています。一つのモデルで計画し、別のモデルでその計画を厳しく検証し、意見の相違を解消してから実行するというものです。

その根底にある主張は、現在のソフトウェア開発には巧妙なプロンプト以上にオーケストレーションが必要だということです。この主張は本格的に検証する価値があります。

既存のテストスイートがある、範囲を限定した機能でこのパターンを試してください。両方の計画を保存し、すべての介入を記録して、通常のワークフローと結果を比較します。

そして、重要な問いを投げかけてください。Fable 5とGPT-5.6 SolのAI開発ワークフローによって、より迅速に検証できるソフトウェアが生まれたのか、それともレビューすべきソフトウェアが増えただけなのか。