Claude CodeやGame Screen Foundryに見るAIエージェント開発の実践知

AIエージェントを開発や運用に活用する動きが活発化する中、現場では実用的な知見やツールの選定が求められています。本記事では、Claude Codeにおけるコンテキスト制限の回避策や、単一AIでのサブエージェント活用の検証結果を紹介します。さらに、ゲーム画面生成を構造化するツールや、氾濫するバズワードとの向き合い方についても解説します。

自動圧縮による挙動のズレを防ぐ3つの回避策

Claude Codeのコンテキスト使用量が100%に達した際に実行される自動圧縮（auto compact）は、直前の指示や制約を忘れて挙動がズレる原因になります。この現象は、会話履歴が自動的に要約に置き換わる際に、細かい制約が要約から落ちてしまうことで発生します。複数リポジトリを横断するルーティンなどで、直前のブランチ判断を忘れて異なるブランチにコミットしようとするなどの問題が報告されています。この挙動のズレを防ぐためには、開発者が圧縮のタイミングや結果をコントロールする必要があります。

この問題に対処する具体的な方法として、PreCompact hookの実装や手動でのコンパクト実行、セッション分割設計の3つが挙げられます。PreCompact hookでは、圧縮直前にセッションログを特定のディレクトリに退避させることで、挙動がズレた際に前提情報を再共有できるようにします。また、コンテキストが80%に達した段階で手動で「/compact」を実行し、残したい前提を明示的に伝えることも有効です。さらに、調査と実装のセッションを分けるなど、1実行あたりの処理範囲を絞る設計にすることで、構造的に問題を回避できます。

出典: Claude Code auto compactが100%でデッドロック——3つの回避策と設計原則

単一AIによるサブエージェントを用いたレビュー検証

単一のAIモデルにおいて文脈を共有しないサブエージェントを構成することは、自己ループでは到達できない誤りの検出に有効です。ある実験では、実装を担当したClaude Codeの測定値の誤りを、レビュー側のサブエージェントが正しく訂正することに成功しました。このレビューでは、レンダリング画像や制約文書などの情報を意図的に絞って渡し、実装側の推論や経緯を遮断することで「誤りの脱相関」を狙いました。結果として、同じモデルであっても文脈を共有しない別インスタンスであれば、実装側の盲点を見つけられることが示されました。

ただし、この手法は1回のレビューで約133万トークンを消費し、所要時間も18分に及ぶため、日常的なダブルチェックには向きません。消費トークンの約9割は安価なキャッシュ読み出しであったため実際の費用は300円程度に抑えられましたが、APIの制限や実行時間の観点から重い処理となります。公式ドキュメントでは検証目的でのサブエージェント使用を推奨していませんが、文脈を共有しない外部の目として構成する点に価値があります。開発者は、どのタスクに対してこのコストを支払うべきかを見極める必要があります。

出典: 単一AIにサブエージェントは必要か — 1回のレビューに133万トークン払って得たものの一例

Game Screen Foundryによる画面生成の構造化

OSSのGame Screen Foundryは、画像生成AIが作成したゲーム画面の一枚絵を、実装で再利用可能な部品へ分解して管理するツールです。生成された一枚絵ではボタンと背景が結合していたり、数値が焼き込まれていたりして、そのままゲームへ組み込むことが困難でした。このツールでは、画面全体のイメージ、素材の座標や重なり順、世界観や共通ルールの3つのJSONファイルで画面を定義します。これにより、見た目を維持しながら文字や数値を実行時にゲーム側で描画する設計が可能になります。

制作フローでは、画像を生成する前にワイヤーフレームで構造を確認し、素材ごとの生成と仮組み、検査、再生成のループを回します。問題のある素材だけを再生成キューに入れることで、すでに採用した素材を維持したまま「特定のボタンだけ余白を増やす」といった微調整が可能です。また、このフローはアプリ上での手作業だけでなく、Claude CodeなどのAIエージェントから扱えるSkillも同梱されています。AIが初稿を作成し、人間がアプリで仕上げるハイブリッドな開発体制を構築できます。

出典: AIが作ったゲーム画面を「一枚絵」で終わらせないために、Game Screen Foundryを作った

氾濫するバズワードとAIスロップへの対処法

AI駆動開発の分野では「グラフエンジニアリング」などのバズワードが急増していますが、その多くは定義が曖昧なAIスロップ（ゴミ情報）です。発端は開発者の1本の問いかけツイートであり、公式な定義や論文が存在しないまま、AIが生成した低品質な解説記事やロードマップが量産されました。中には架空の共同研究やコースを捏造した投稿まで出回り、情報汚染が進んでいます。また、制御グラフやナレッジグラフといった別分野の技術用語が1つの記事の中で混同して語られるケースも目立ちます。

このような情報汚染に対処するためには、解説記事を鵜呑みにせず、元の投稿や公式ドキュメントといった一次ソースに当たることが重要です。特に「大手企業が一斉に採用した」といった権威を偽装する主張や数字は真に受けず、言葉の波が落ち着くまで静観する姿勢が求められます。多くの開発タスクにおいて複雑なグラフ構造は過剰であり、ワークフローが直線的であれば直線のまま維持する方が賢明です。バズワードの名称に惑わされることなく、作業の分割や実行の制御といった本質的な工学的問題に目を向けるべきです。

出典: AIスロップによる汚染に注意 - 「グラフエンジニアリング」って結局何？ -

この日の動きをどう見るか

AIエージェントを開発プロセスに組み込む際、コンテキストの制限や生成物の再利用性、そして氾濫する情報の見極めといった実務的な課題が浮き彫りになっています。Claude Codeの自動圧縮への対策や、Game Screen Foundryのような構造化ツールの登場は、AIとの協調をより確実なものにするためのアプローチです。

また、サブエージェントによる検証や、新たなバズワードである「グラフエンジニアリング」の流行は、エージェントの制御やワークフローの高度化に対する関心の高まりを示しています。開発者は、技術の表面的な流行に流されることなく、コスト対効果や一次ソースに基づく正確な情報を評価し、自社の開発環境に適したツールや設計を選択することが求められます。