AIエージェントの本質はwhileループだった：Agent LoopとLoop Engineering入門

投稿日 2026/06/29 更新日 2026/06/29

投稿者 hantani

56 分で読めます

「AIって、もう何でもできるんでしょ？」

そう聞かれるたびに、少しだけ立ち止まりたくなります。できることはたしかに増えた。でも「何でもできる」は正確じゃない。AIエージェントが強くなっているのは、正しく設計されたループのなかで動いているからです。

この記事では、AIエージェントの本質である「Agent Loop（エージェントループ）」と、2026年6月に一気に注目を集めた「Loop Engineering（ループエンジニアリング）」という考え方を、できるだけわかりやすく、でも技術的に正確に解説します。

「AIエージェントって何となくわかるけど、実装イメージが湧かない」「Claude CodeやCodexを使い始めたけど、どう使えばいいのか」——そんな人にとって、腹落ちのきっかけになればと思います。

1. いま「AI Agent Loop」が熱い

2025年から2026年にかけて、AIエージェントをめぐる空気が変わりました。

変化の一つは、OpenAIが「A practical guide to building agents（AIエージェント構築の実践ガイド）」という34ページの公式ドキュメントを公開したことです。このガイドは、製品チームやエンジニアリングチームがエージェントシステムを作るための知識とベストプラクティスをまとめたもので、実際の顧客事例から得られた知見が詰まっています。

このガイドで特に注目されているのは、AIを動かす「run（実行単位）」がツール呼び出しや終了条件まで繰り返すループとして設計・説明されている点です。AIを1回呼び出して終わり、ではなく、目的を与えて、ツールを使わせて、結果を観測して、また判断させる。公式ドキュメントのこの構造から、エージェントをループとして理解できる、という見方が広まっています。

もう一つの変化は、Claude Code、Codex（OpenAI）、Cursor、DevinのようなAIコーディング環境が実用域に入ってきたことです。個人開発者でも、AIエージェントに「調査→実装→テスト→修正→再テスト」のループを回させて、アプリやゲームを作る事例が出てきています。

そして2026年6月、「Prompt Engineering（プロンプトエンジニアリング）」の次に来る概念として、「Loop Engineering（ループエンジニアリング）」という言葉が広まり始めました。GoogleのエンジニアリングリーダーであるAddy Osmaniが発表した記事が火付け役となり、O’Reillyのレーダーにも掲載されるなど、急速に注目を集めています。

以前のAI活用は「質問して、答えをもらう」でした。
でも今のAIエージェントは、「作業して、結果を見て、直して、また試す」で動きます。

つまり、AIとの付き合い方が「チャット」から「作業ループ」へと変わりつつある。

これがわかると、Claude CodeやCodexをどう使えばいいか、なぜうまく動くときと動かないときがあるのかが、ずっとクリアになります。

2. AIエージェントは「モデル1回呼び出し」ではない

まず、普通のAIチャットとAIエージェントの違いを整理します。

普通のAIチャット：

ユーザーが質問する
モデルが回答する
基本的には1往復で終わる

ChatGPTやClaudeに「この関数を説明して」と聞いて、答えをもらう。これは1回のモデル呼び出しです。

AIエージェント：

ユーザーが目的を与える
モデルが次にやることを決める
必要ならツールを呼ぶ（ファイルを読む、コードを実行する、Web検索するなど）
ツール結果を読む
さらに次の判断をする
完了条件まで繰り返す

この違いを、疑似コードで表現するとこうなります。

  
# これは考え方を示す疑似コード（実際の実装ではありません）
while not done:
    thought = model(context)         # モデルを呼ぶ
    action = decide_next_action(thought)

    if action.type == "tool_call":
        result = run_tool(action)    # ツールを実行する
        context.append(result)       # 結果を文脈に追加する

    elif action.type == "final_answer":
        done = True
        return action.output         # 完了

    if too_many_steps:
        raise Exception("max turns exceeded")  # 上限で止める

これはあくまで「考え方を示す疑似コード」であり、厳密な実装コードではありません。でも、エージェントの動き方をつかむには十分です。

ポイントはループです。モデルを呼ぶ → ツールを使う → 結果をコンテキストに追加する → もう一度モデルを呼ぶ。この繰り返しがAIエージェントの本体です。

3. OpenAI公式ガイドが示した「Agent = Loop」という見方

OpenAIのAgents SDK（公式ライブラリ）には、Runner.run() というメソッドがあります。

このメソッドを呼ぶと、AIエージェントは以下の流れでループを回します。

ステップ1：モデルを呼ぶ
現在の入力と文脈（コンテキスト）をもとにLLMを呼び出します。

ステップ2：出力を判定する
モデルの出力が何かによって、次の動作が変わります。

最終出力（final output）が返ってきた場合 → ループ終了
ハンドオフ（handoff）が返ってきた場合 → 別のエージェントへ切り替えてループ継続
ツール呼び出し（tool call）が返ってきた場合 → ツールを実行してループ継続

ステップ3：ツール結果を追加して再実行
ツールを使った場合は、その結果をコンテキストに追加して、もう一度モデルを呼びます。

ステップ4：終了条件の確認
max_turns（最大ターン数）を超えると MaxTurnsExceeded という例外が発生してループが止まります。

実際のコードでは、こんなふうに書きます。

  
import asyncio
from agents import Agent, Runner

agent = Agent(
    name="bug-fixer",
    instructions="エラーログを読んで、バグを修正してください。",
)

async def main():
    result = await Runner.run(
        agent,
        "ログイン時に500エラーが発生しています。関連ファイルを確認してください。",
        max_turns=10,  # 最大10ターンで止める
    )
    print(result.final_output)

asyncio.run(main())

ここで重要なのは「ツールの結果をAIに戻す」というステップです。

ただのチャットなら、AIが「〇〇ファイルを見てください」と言って終わりです。しかしエージェントは、AIが「このファイルを読め」と指示したら、実際にファイルを読んで、その内容をコンテキストに追加して、AIにまた渡します。

結果を観測して、次の行動を変える。だからエージェントになる。

この「観測してフィードバックする」というステップを省略すると、どれだけ高性能なモデルを使っても、ただの「ツール付きチャット」です。

4. Loop Engineeringとは何か

2026年6月、Addy Osmani（Googleのエンジニアリングリーダー）が「Loop Engineering」という概念を発表しました。記事はブログだけでなく、O’Reilly RadarやSubstackでも公開され、瞬く間に話題になりました。

Osmani氏の定義をわかりやすく言い換えると、こうなります。

Loop Engineeringとは、「自分がエージェントにプロンプトを送り続ける役割」を、自動化されたシステムに委譲すること。つまり、AIに指示するのではなく、AIが指示を受け続ける仕組みを設計すること。

もう少し具体的に言うと、

AIエージェントが目的を達成するまで反復できるように、目的・文脈・ツール・観測方法・検証基準・終了条件・安全策を設計することがLoop Engineeringだ。

この定義で、Prompt Engineering（プロンプトエンジニアリング）との違いが明確になります。

Prompt Engineering：

どんな入力をモデルに渡すか
どう書けば良い回答が出やすいか
主に「1回のモデル呼び出し」を改善する技術
人間が各ステップで指示を送る

Loop Engineering：

モデルを何回、どの条件で呼ぶか
どのツールを使わせるか
結果をどう観測させるか
失敗時にどう修正させるか
どこで止めるか
人間がどこで介入するか
フィードバックはテスト・ログ・ビルド結果などが担う

わかりやすい比喩で言えば、

Prompt Engineeringは「良い指示文を書く技術」。
Loop Engineeringは「AIが作業し続ける作業場を設計する技術」。

料理で例えるなら、Prompt Engineeringは「シェフに良いレシピを渡すこと」。Loop Engineeringは「シェフが自動で食材を確認し、調理し、味見し、調整し続ける厨房全体を設計すること」です。

Kilo AIの解説では、Loop Engineeringのサイクルを「インテント（目的）→ コンテキスト（文脈）→ アクション（行動）→ オブザベーション（観測）→ アジャストメント（調整）」という5段階で説明しています。

Osmani氏の記事では、ループを構成する要素として「Automations（自動化）・Worktrees（並列作業ツリー）・Skills（スキル文書）・Connectors（外部ツール連携）・Sub-agents（副エージェント）」の5つが挙げられており、Claude CodeとCodexはすでにこれらを備えている、とも述べています。

5. Agent Loopの基本構造

Agent Loopを自分で設計するとき、意識すべき5つの要素があります。

5-1. Goal：目的を決める

目的はできるだけ具体的に書きます。

悪い例：

このアプリをいい感じにして

良い例：

ログイン画面でパスワード表示切替ボタンを追加し、
既存のUIスタイル（tailwindのbtn-primaryクラス）に合わせてください。
既存のテストを実行し、全て通ることを確認してください。

目的が曖昧だと、AIエージェントは広い意味で解釈しようとします。「いい感じ」は人間でも定義できないので、AIはなんでも変えようとします。変更範囲が広がり、意図しない修正が増えます。

目的を書くとき、「何をもって完了とするか」を一緒に書くと、ループの終了条件が明確になります。

5-2. Context：文脈を集める

AIエージェントは、文脈がないと危険な推測をします。

「なんとなく動いてそう」な実装をする、既存のコードパターンを無視した別スタイルで書く、関係のないファイルを変更する——これらは文脈不足が原因であることがほとんどです。

必要な文脈の例：

関連ファイルとその役割
README（プロジェクトの概要）
既存の実装パターン（どのライブラリを使っているか）
エラーログ
テスト結果
コーディング規約
変更してよい範囲と変更してはいけない範囲

Claude Codeなら、最初に「まず関連ファイルを調査してください」と書くだけで、コードベースを把握してから作業を始めます。この1ステップがあるかないかで、結果の精度が大きく変わります。

5-3. Action：小さく行動する

AIに一気に大改造させないことが重要です。

変更単位を小さくするメリットは2つあります。1つは、問題があったときに原因を特定しやすいこと。もう1つは、差分をレビューしやすいこと。

Claude Codeなどに伝えると効果的なルール：

最小限の変更で目的を達成すること
既存のパターンに合わせること
不要なリファクタリングをしないこと
大きな設計変更が必要な場合は作業を止めて報告すること

「できる限り手を加えない」というルールを明示すると、AIは過剰に変更しようとするクセを抑えます。

5-4. Observation：結果を観測する

ここがAgent Loopの心臓部です。

AIが「できました」と言うだけでは不十分です。AIは自信を持って間違えることがあります。外部の観測結果で確認することが必要です。

観測の例：

テスト結果（通ったか落ちたか）
型チェックの結果（TypeScript / mypy）
lintの結果
ビルド結果
実行ログ
スクリーンショット（UIの変更なら）
差分（git diff）
APIレスポンス

テストを実行して、ビルドして、lintを通す——これらの結果がAIに戻ることで、エージェントは「自分が正しいかどうか」を判断できます。観測できない作業は、エージェントには向いていません。

5-5. Adjustment：結果を見て修正する

テストが落ちた場合、良いエージェントはこう動きます。

失敗ログを読む
原因を推測する
該当ファイルを確認する
修正する
再テストする

これが、AIエージェントらしさの中心です。人間が毎回「次はここを直して」と指示するのではなく、AIが失敗を読んで自ら次の行動を変える。この自己修正ループが機能するから、複雑な作業を任せられます。

ただし、修正回数には上限を設けてください。「何回失敗しても諦めず直し続ける」は聞こえはいいですが、実際には同じ間違いを繰り返したり、場当たり的な修正で問題を隠蔽したりするリスクがあります。「3回失敗したら停止して報告」のような終了条件が必要です。

6. Claude Codeで考えるAgent Loop

Claude Codeを使うとき、「何をするか」だけでなく「どう確認するか」「どこで止まるか」まで書くと、ループの質が大きく上がります。

例1：バグ修正ループ

目的： ログイン時に特定条件で500エラーが出る問題を直す

ループ：
関連ファイルとエラーログを調査する
原因候補を3つ以内に整理する
最小限の修正を行う
既存テストを実行する
失敗したらログを読み、修正を試みる（最大3回）
成功したら差分を要約する
変更範囲が広すぎないか確認する

例2：記事作成ループ

目的： AI Agent Loopに関する技術ブログを書く

ループ：
公式ドキュメントや一次情報を調査する
確認できた事実と推測・意見を分ける
読者像を想定する
見出し構成を作る
初稿を書く
初心者にわかりにくい箇所を補足する
事実確認が必要な箇所を一覧にする

例3：個人開発ループ

目的： シンプルなタスク管理Webアプリを作る

ループ：
要件を箇条書きで整理する
最小構成を提案する
既存ファイルがあれば確認する
最小実装を行う
起動方法をREADMEに書く
実行確認できるコマンドを提示する
エラーが出た場合はログを読んで修正する

共通しているのは、「調査→実行→観測→修正」という流れです。Claude Codeはこのループを自然に回してくれますが、設計が曖昧だと、どこかのステップで迷走します。

7. 個人開発者によるGTA風ゲーム開発が示すもの

2026年6月、AI startup Hyperechoを創業した25歳のZiwen Xuが、Xで毎日進捗を投稿しながらゲームを開発するプロジェクトが話題になりました。

Xu氏本人が「a loop of AI agents で GTA6クラスのオープンワールドゲームを作る」と宣言して始まったプロジェクトで、Claudeを中心にAIエージェントを連鎖させた「vibe coding」と呼ばれる手法で進めています。メディアでは「GT-Caliber」と紹介されることもありますが、Xu氏自身の表現は “GTA-VI-caliber open-world game”（GTA6に匹敵するクオリティのゲーム）です。

GTA6はRockstar Gamesの商標・著作物です。このプロジェクトは独立した個人開発プロジェクトであり、Rockstar Gamesとは無関係です。商用化や配布には権利面での確認が必要になる点には注意してください。

進捗の概要：

Day 1：基本的な3D環境が出来上がり、キャラクターが動き始める
Day 3：NPCが歩き、車が走り、武器システムが入り、影と反射も動作し始める
Day 4：NPCと車にモデルが付き、実際の運転システム、交通ルールが追加される
Day 7：街全体が生成されるが、Claudeが誤ってマイアミではなくロサンゼルスを作ってしまう
Day 8：全エージェントが一斉にゲームを起動してスクリーンショットを撮ろうとしたせいで、Macが落ちる

エンジンもGodot → Unreal Engine 5と複数回変更しており、混乱やエンジン変更、やり直しが伴う開発です。

これは「AIが魔法でゲームを作った」という話ではありません。

むしろ、人間が目的を与え、AIに実装させ、結果を確認し、次の課題を与えるループが機能している事例です。間違った都市を作ってしまった、エンジンが合わなかった、Macが落ちた——これらの失敗を含めて、Agent Loopらしい開発です。

Xu氏はClaude Max 20x（月に大量のトークンを使用できるプラン）にアップグレードして挑んでいますが、それでも1日で週の使用量の33%を消費することがありました。トークンコストは、Agent Loopを設計するうえで無視できない要素です。

この事例が示しているのは、「AIエージェントのループがあれば、個人開発者も大規模な作業に挑戦できる可能性がある」ということです。ただし、それは「人間がループの設計者・監督者・修正者でいる」からこそ成り立ちます。

8. なぜ今、Loop Engineeringが重要になったのか

なぜ今になってこれが重要なのか。いくつかの理由があります。

モデルがツールを使えるようになった

以前のAIは「テキストを生成するだけ」でした。今のモデルは、ファイルを読む、コードを実行する、Web検索する、APIを呼ぶ、テストを実行する——これらを自律的に行えます。ループを回す素材が揃ったことで、Agent Loopが現実的になりました。

コーディングエージェントが実用域に入った

Claude Code、Codex、Cursor、Devin系のツールは、今やただの「補完ツール」ではありません。複数ファイルをまたいで変更し、テストを実行し、失敗ログを読んで自己修正できます。実務で使えるレベルに達しています。

単発プロンプトでは実務の複雑さに耐えにくい

本番のコードベースは複雑です。既存の実装パターン、依存関係、テスト、環境差分、仕様変更、エッジケース——これらをすべて一発のプロンプトで扱うのは現実的ではありません。何度も調査して、少しずつ変えて、確認する。そのためのループが必要です。

観測できる作業はAIに向いている

「テストが通るか」「ビルドできるか」「lintが通るか」「ファイルが生成されたか」「APIが期待通りのレスポンスを返すか」——これらは機械的に確認できます。AIが自己評価できる作業は、ループに乗せやすい。

人間の役割が変わる

これが最も重要な変化かもしれません。

以前の開発者：直接コードを書く人
今の開発者：AIに指示を送る人
これからの開発者：AIが働くループを設計する人

9. 良いAgent Loopの条件

9-1. 目的が明確

「何をもって完了とするか」が書いてあること。曖昧な目的だとループが迷走します。

9-2. 観測可能

テスト、ログ、ビルド、差分など、AIが結果を見て判断できる材料があること。観測できない作業をループに乗せると、AIは自分の判断だけで進み続けます。

9-3. 小さく進める

大きな変更を一度にやらせない。小さく変更して、小さく検証する。これが積み重なって、大きな成果になります。

9-4. 終了条件がある

終わらないループは危険です。最大ターン数、最大試行回数、人間確認のチェックポイント、エラー時停止——これらを明示します。

9-5. 人間の介入点がある

以下の場面では、人間の確認を挟むのが安全です。

仕様が曖昧なとき
大量のファイルを変更するとき
外部APIや本番環境に触るとき
課金が発生するとき
セキュリティに関わるとき
データ削除を行うとき

9-6. ログが残る

AIが何をしたか、なぜそうしたか、どのテストを通したかが追えること。あとから人間がレビューできることが、安全なAgent Loopの条件です。

10. 悪いAgent Loopの例

悪い例1

このリポジトリを全部いい感じに直して。
動くまで頑張って。

問題点：

目的が曖昧（「いい感じ」は定義できない）
終了条件がない（「動くまで」はいつまでも続く可能性がある）
変更範囲が広すぎる
検証方法がない
暴走しやすい

悪い例2

エラーが出たら何でもいいので直して。

問題点：

原因を確認せず場当たり的に修正する可能性がある
余計な変更が増える
テストにだけ合わせた「テスト過剰適合」になる危険がある
本質的な設計問題を隠してしまう可能性がある

良い書き換え

ログイン画面で発生している500エラーを調査してください。

進め方：
1. まず関連ファイルとエラーログを確認する
2. 原因候補を3つ以内に整理して、作業前に報告する
3. 最小限の修正を行う
4. 既存のテストを実行する

失敗した場合：
- 失敗ログを読んで修正を試みること
- 最大3回まで試みること
- 3回で解決しない場合は停止し、原因候補と未解決点を報告すること

禁止：
- 無関係なファイルの変更
- 仕様外の機能追加
- テストを削除して通す行為

11. Claude Codeに渡す実用プロンプト例

そのまま使える例を3つ紹介します。

バグ修正用

このリポジトリで発生している不具合を修正してください。

目的：
[不具合の内容を書く]

進め方：
1. まず関連ファイルを調査してください
2. 変更前に原因候補を簡潔に説明してください
3. 最小限の修正を行ってください
4. 既存のテスト、型チェック、lintのうち実行可能なものを実行してください
5. 失敗した場合はログを読み、最大3回まで修正を試してください
6. 3回で解決しない場合は停止し、原因候補と次に確認すべき点を報告してください

禁止：
- 無関係な大規模リファクタリング
- 仕様外の機能追加
- 本番データの変更
- 秘密情報の出力

記事作成用

以下のテーマで技術ブログ記事を書いてください。

テーマ：
[テーマを書く]

進め方：
1. まず一次情報（公式ドキュメント、発表資料）を調査してください
2. 確認できた事実と、推測・意見を分けてください
3. 読者像（初心者〜中級者）を想定してください
4. 見出し構成を作ってください
5. 初稿を書いてください
6. 初心者にわかりにくい専門用語を補足してください
7. 最後に、事実確認が必要な箇所を一覧にしてください

文体：
- やさしく、具体例多め
- 技術的に正確に
- 断定しすぎない（確認済みと推測を分ける）
- 煽らない

個人開発用

小さなWebアプリを作ってください。

目的：
[作りたいアプリを書く]

進め方：
1. 要件を箇条書きで整理してください
2. 最小構成を提案してください
3. 既存ファイルがあれば確認してください
4. 最小実装を行ってください
5. 起動方法をREADMEに書いてください
6. 実行確認できるコマンドを提示してください
7. エラーが出た場合はログを読んで修正してください

終了条件：
- ローカルで起動できる
- READMEの手順で再現できる
- 主要機能が1つ動く

禁止：
- 使わない機能の先行実装
- テストを削除して通す行為
- 大規模な設計変更（必要な場合は事前に相談する）

12. Agent Loopのリスク

良いことばかりではありません。Agent Loopにはリスクが伴います。

コスト面のリスク：

トークン消費が大幅に増える（ループが1ターン増えるたびにコストが増える）
ループが長くなりすぎると、1タスクで想定外のコストが発生する

品質面のリスク：

間違った方向に自己修正し続ける（修正が積み重なって原因が見えなくなる）
テストにだけ過剰適合する（本質的な問題を隠す修正をする）
仕様を勝手に解釈して、意図しない実装をする

安全面のリスク：

変更範囲が広がる（禁止していないファイルまで変更する）
APIキーや秘密情報を扱う処理が入り込む可能性がある
本番環境で危険な操作をしてしまう可能性がある
データ削除や不可逆な変更をする可能性がある
著作権や商標を無視した出力をする可能性がある

対策：

最大試行回数・最大ターン数を設定する
変更前に計画（原因候補・修正案）を出させる
差分を確認してからマージする
本番環境への操作を明示的に禁止する
外部API・データ削除・課金処理には人間承認を挟む
ログを残す（何をしたか、なぜそうしたかが追えるように）
タスクを小さく分割する

13. これからの開発者に必要なスキル

これからの開発者に求められるスキルは変わってきています。

「良いプロンプトを書く力」は引き続き必要ですが、それだけでは不十分です。

目的を分解する力。 「いい感じにして」を「何を・どう変えて・何で確認するか」に落とし込む力です。

検証可能な作業に落とす力。 テスト、ログ、ビルド結果など、機械的に確認できる形にする力です。

テストを書く力。 AIエージェントが自己検証できるかどうかは、テストの質に大きく依存します。

ログを読む力。 AIが何をしたか、なぜ失敗したかをログから読み解く力です。

AIの出力をレビューする力。 「できました」を鵜呑みにせず、差分を読んで意図通りかを確認する力です。

安全な自動化範囲を決める力。 どこまでAIに任せてよいか、どこで人間が介入するかを判断する力です。

そしてループを設計する力。 これが最も新しく、最も重要なスキルかもしれません。

結論として：

これから重要なのは、AIに一発で正解を出させることではありません。
AIが間違えても観測し、直し、また試せる構造を作ることです。

つまり、開発者は「答えを聞く人」から、「AIが働くループを設計する人」へと変わっていきます。

14. まとめ

AIエージェントの本質は、単発のモデル呼び出しではなくループである
OpenAIのAgents SDKでも、Runner.run は終了条件（final output / max_turns）まで回るループとして実装されている
Loop Engineeringは、目的・文脈・行動・観測・修正・終了条件を設計する考え方であり、2026年6月のAddy Osmaniの記事をきっかけに注目が集まった
Claude CodeなどのAIコーディングエージェントでは、「ループをどう設計するか」が品質と安全性を左右する
Ziwen Xu氏のGTA風オープンワールドゲーム開発のように、個人開発者でも Agent Loop を活用した大規模な挑戦が出てきている
ただし、コスト・安全性・著作権・暴走防止には常に注意が必要
これからの開発者は、プロンプトを書く人から、AIが働く仕組みを設計する人へと変わっていく

まずは大きな自動化を狙わなくてよいです。

「調べる → 直す → テストする → 失敗を読む → もう一度直す」

この小さなループをClaude Codeに任せるところから始めると、AIエージェントの本質が自然と見えてきます。

Claude Codeで試せる小さなAgent Loop例

次のプロンプトをClaude Codeに渡してみてください。小さくてもAgent Loopの本質を体験できます。

このリポジトリのREADMEを読み、次の作業を行ってください。

目的：
src/ 配下にある未使用のimport文を1ファイルだけ選んで削除してください。

進め方：
1. まずREADMEとpackage.jsonを読んでください
2. 未使用importがあるファイルを1つ特定してください
3. 変更前に「どのファイルの何行目を変更するか」を報告してください
4. 最小限の変更を行ってください
5. lintまたは型チェックを実行してください（使えるものだけ）
6. 失敗した場合はログを読んで修正してください（最大2回）
7. 完了後、変更内容を1〜2行で要約してください

禁止：
- 複数ファイルの同時変更
- リファクタリング（import削除以外の変更）
- テストの変更

これだけで、調査 → 確認 → 実行 → 観測 → 調整、という小さなAgent Loopが動きます。

参考情報

事実確認メモ

確認済みの情報：

OpenAI Agents SDK の Runner.run が LLM呼び出し → tool call → result追加 → 再実行 → final output or max_turns で終了する、というループ構造を持つことは公式ドキュメントで確認済み
Addy Osmaniの “Loop Engineering” 記事がブログ、O’Reilly Radar、Substack（Elevate）で公開されていることは確認済み
Loop Engineeringの5構成要素（Automations, Worktrees, Skills, Plugins/Connectors, Sub-agents）はOsmani氏の記事の記述に基づく
Ziwen Xu氏がHyperecho創業者でAIエージェントのループを使ってGTA風ゲームを開発中であることはGizmodo、autoevolution等の複数メディアで確認済み
Day 1〜7の進捗（NPCの追加、エンジン変更、LAを誤生成など）は複数のメディア記事で確認済み
Claude Max 20xを使用していることはGizmodo記事で確認済み

追加確認が望ましい情報：

Day 18以降の具体的な進捗詳細（影・車の反射・アニメーション等の特定の日付の状況）はXの投稿原文を直接確認することを推奨
「プロジェクト名GT-Caliber」という呼称の正確さ（Gizmodoなど複数メディアに記載があるが、Xu氏本人の表現は “GTA-VI-caliber open-world game”）
OpenAI “A practical guide to building agents” PDFの詳細な引用（PDFとして公開されており直接参照が必要）
Kilo AIの Loop Engineering 解説記事の更新状況

AI, 技術解説

この投稿は投稿者によって CC BY 4.0 の下でライセンスされています。