「良い​プロンプト」の​次は、​「良いループ」だった​ ──Codex・Claude Code・GitHub・Grokが​向かう、​AI開発の​新しい​主戦場

技術ノート ｜ AIの最新動向を、現場目線で

ここ数年、AIで開発する人の合言葉は「どんなプロンプトを書けば、うまく動くか」だった。良い指示の型、コンテキストの渡し方、出力フォーマットの縛り方──プロンプトエンジニアリングが主戦場だった。ところが 2026年6月の、ほんの数日間で、その前提が静かにずれ始めた。

6月7日、Google系の開発者体験で知られる Addy Osmani が「Loop Engineering（ループ・エンジニアリング）」という整理を公開した。^[1] その前後で、GitHubは Agentic Workflows をパブリックプレビューにし^[2]、Anthropicは Claude Code に dynamic workflows と定時実行エージェントを押し出し^[5]、xAIは Grok の plugin marketplace を開いた^[4]。OpenAI Codex の公式ドキュメントも、一発のプロンプトより AGENTS.md・skills・subagents・automations を前面に置いている。^[3]

私たち電脳技巧集団（AI職人ギルド）は、毎日AIエージェントでものを作っている。だからこの流れを、流行語としてではなく「で、作る側の設計はどう変わるのか」という目線で読む。何が変わったのか、maker / checker / state という補助線で各社の製品を読み解き、そして私たち自身がすでにこの"ループ"で記事も製品も作っているという一次情報まで、順に整理する。

012026年6月、​各社が​同じ​場所に​寄ってきた

まず事実を、時系列で押さえる。「ループ」という言葉が一人歩きしているわけではない。主要プレイヤーの製品の出し方が、数日のうちに同じ方向へ揃ったことが、この話の骨格だ。^[1]

時点（2026年）	出来事
4月14日	Claude Code が routines を公開。プロンプト＋リポジトリ＋接続先を一度定義し、定時・API・イベントで実行可能に
5月28日	Anthropic が dynamic workflows を発表。大きな仕事を並列サブエージェント＋検証＋進捗の永続化で回す形を製品化
6月7日	Addy Osmani が 「Loop Engineering」 を公開。automations / worktrees / skills / connectors / subagents / memory を一つの抽象にまとめる
6月9日	Claude の Managed Agents に定時デプロイと vaults（秘密情報の保管）が追加
6月11日	GitHub が Agentic Workflows をパブリックプレビュー公開。同日、個人アクセストークン不要化で組織運用へ前進
6月11日	xAI が Grok Build Plugin Marketplace を公開。skills / hooks / agents / MCP / LSP を1パッケージで配る設計

※ 各社の公式発表・公式ドキュメント（2026年4〜6月）に基づく。「各社が同じ方向に寄っている」という見立て自体は、CAGによる複数製品の構造比較（解釈）。

偶然の重なりにしては、出てきた機能の形がよく似ている。定時実行、並列サブエージェント、再利用可能なskill／plugin、外部に残す状態（memory／state）、そして検証。違う会社が、申し合わせたように同じ部品を揃え始めた──ここに、潮目の変化が見える。

02​「良い​プロンプト」​時代に、​何に​消耗していたか

プロンプトエンジニアリングが悪かったわけではない。むしろ土台として、今も効く。問題は、一回の会話の品質を上げることだけに投資し続けると、ある天井にぶつかることだ。

うまい指示を一発書いても、セッションが終われば文脈は消える。同じ作業を翌日もう一度やるには、また同じ説明から始める。出力が正しいかは結局自分で目視する。少し大きな仕事になると、一つの会話の中で「考える役」も「直す役」も「覚えておく役」も全部一人のAIが兼ねるので、長くなるほど取りこぼす。「うまく頼む」だけでは、仕事は積み上がらないのだ。

ループ・エンジニアリングの出発点は、この消耗を「設計で吸収する」という発想だ。良い指示を書く人ではなく、その指示を"回す仕組み"を設計する人になる──Addy Osmani の整理を一言で言えば、そういうことになる。^[1]

03ループの​正体は、​maker / checker / state の​分離

では「良いループ」とは具体的に何か。Addy の整理の中核は、驚くほどシンプルだ。作る役（maker）、検証する役（checker）、覚えておく場所（state）を分ける。^[1] これに「定時で回す（schedule）」「型を再利用する（skills）」を足すと、ループの骨格になる。

なぜ「役を分ける」だけで効くのか。ポイントは checker を maker とは別人格にすることにある。同じAIに「作って、ついでに自己採点して」と頼むと、自分の答えに甘くなる。作った本人とは別のエージェントに「これは本当に正しいか、むしろ間違いを探せ」と反証させると、間違いが格段に残りにくい。これは人間のレビューと同じ理屈だ。

そして state。出力をその場で消費せず、Markdownや課題管理ツールに"事実"として残す。次の周回はそこから文脈を取り直すので、セッションが切れても積み上がる。02章で挙げた「翌日また同じ説明から」が消える。これがループが回る最低条件だ。

04各社の​製品を、​同じ図に​当てはめる

面白いのは、Codex・Claude Code・GitHub・Grok というバラバラに見える製品が、maker / checker / state の図にきれいに収まることだ。名前は違っても、揃えている部品はほぼ同じ。^[2][3][5]

具体的に、各社が何を「ループの部品」として持っているかを並べると、収束ぶりがはっきりする。

ループの部品	各社の対応する機能
maker（作る）	Codex の subagents／Claude Code の並列サブエージェント／GitHub Actions 上のエージェント
checker（検証）	Claude の dynamic workflows は「結果が検証される」を明記／GitHub は CI失敗の解析・safe outputs
state（残す）	Claude は「進捗が保存される」／Codex の goals／GitHub の issue・PR が状態の置き場
schedule（回す）	Claude Code の routines・定時デプロイ／Codex の automations／GitHub Actions のトリガー
skills / plugins（型）	Codex の AGENTS.md・skills／Claude の skills／Grok は skills・hooks・agents・MCP を1プラグインに束ねる

※ 各社公式ドキュメント・発表（2026年4〜6月）の記述に基づく整理。CAG自身がすべての製品を横並びでベンチマークしたわけではない。

GitHub と xAI の動きは、もう一つ別のことを示している。GitHub は workflow を Markdown と Actions に落として組織課金・権限・レビューに接続した^[2]。個人のターミナル技から、チームのSDLC機能へ移したのだ。xAI は plugin を「ループの構成部品を配る単位」にした^[4]。どちらも、ループを個人の手元で終わらせず、組織と流通に乗せる方向を向いている。

05​私たちは、​すでに​この​ループで​作っている

ここまでは外の動向だ。だが私たち電脳技巧集団にとって、これは新しい流行ではなくすでに毎日やっていることでもある。一次情報として、いくつか実例を出す。

たとえば、あなたが今読んでいるこの記事自体が、ループの産物だ。CAGの記事制作は、題材選定→執筆→図版化→画像生成→検証→公開という手順を、再利用可能なskillとして固定している。毎回ゼロから「CAGの記事ってどう書くんだっけ」を説明し直さない。手順・規約・チェックリストが state として残り、新しい学びがあればその場でskillに焼き込む。まさに skill＋state＋verify のループだ。

もっとはっきりした例が、このサイトに常駐する顧客対応AIだ。これは maker / checker / state を地で行く設計で組んである。AIが見積もりや返信を作り（maker）、重要な判断は人間が承認するHITLという検証関門（checker）を必ず通す。そして顧客ごとの専用メモリ（state）に履歴を残し、次の会話へ文脈を渡す。作りっぱなしにしない、人格を分けて検証する、状態を外に残す──ループの3点セットがそのまま製品になっている。

関連記事 ｜ maker/checker/state を製品にした実例このサイトのAIは、自分たちで作った ──HITL・顧客別メモリ・双方向を実装した顧客対応AIの中身 →

だから今回の各社の動きは、私たちにとって「自分たちのやり方が、業界の標準として言語化された」という感触に近い。Addy Osmani の整理は、私たちが現場で「こうすると壊れにくい」と経験的に掴んでいたものに、きれいな名前を与えてくれた。

06何が​変わって、​何は​まだ​変わっていないか

ここで、煽りすぎないために釘を刺しておく。「プロンプトエンジニアリングは終わった」は誇張だ。^[1] OpenAIもAnthropicも、依然としてプロンプト・コンテキスト・制約の設計を重視している。変わったのは「プロンプトが消えた」ことではなく、その上に harness／workflow／loop という上位レイヤーが乗ってきたことだ。土台は土台として残る。

注意点も同じだけある。ループは無料ではない。並列にエージェントを回せばトークンコストはむしろ増える。そもそも検証（checker）を書けない仕事をループ化すると、間違いを高速で量産するだけになる。テストが緑になっても、それは「理解した」の代わりにはならない──私たちはこの"静かに壊れる"失敗を、過去に何度も現場で踏んできた。判断の重い仕事ほど、最後は人間のレビューが要る。「ループを回せば無人開発できる」は、まだ誤解だ。

07​締め：勝負軸は​「何を​頼むか」から​「どう​回すか」​へ

2026年6月の数日間を、現場目線でまとめる。

一つは、AI開発の差分が「モデル比較」や「うまい一言」から、運用構造の設計へ移り始めたこと。誰が作り、誰が（別人格で）検証し、何を外部状態として残し、どの cadence で回すか──この設計力が、これからの差になる。Codex も Claude Code も GitHub も Grok も、別々の入口から同じ場所へ歩いている。

もう一つは、それでもプロンプトという土台と、人間という最後の砦は消えないこと。上位レイヤーが増えたぶん、「どこを自動で回し、どこで人が責任を持つか」を線引きする設計が、むしろ重要になった。私たちが大切にしているHITL（重要判断は人間が承認）は、まさにこの線引きそのものだ。

電脳技巧集団（AI職人ギルド）は、最新のAIを誰よりも貪欲に使いこなす。同時に、その使い方を一発の魔法ではなく、壊れにくいループとして設計することを本業にしている。良いプロンプトの先にある「良いループ」を、お客さまの仕事の上に組む──それが、AIで飯を食う職人の腕の見せどころだ。

「うまく頼む」から「うまく回す」へ。この変化を、一枚に。

観点	プロンプト中心の発想	CAG（ループで設計する）
主役	うまい一言の指示	作る・検証する・残す仕組みの設計
検証	作った本人が自己採点	別人格のcheckerが反証＋人のHITL
記憶	セッションが切れたら消える	外部state（memory/Markdown）に残す
再現性	毎回ゼロから説明し直す	再利用可能なskillに型を固定
運用	手元で都度起動	定時・イベントで回す（schedule）
失敗時	気づかず量産（静かに壊れる）	検証関門と人の承認で止める

※ 本記事は外部の公式発表・記事を、開発実務の観点から整理・論評したもの。各社機能の事実関係は下記出典に基づく引用であり、製品横並びのベンチマークはCAG自身が検証したものではない（「各社が同じ方向に収束している」は複数製品からの解釈）。CAGのループ運用に関する記述は自社の一次情報。状況は流動的で、各製品の仕様は更新されうる（v0・2026-06-14時点）。