ソフトウェアエンジニアの仕事は「ループを書くこと」になる　内側ループと外側ループ（ハーネス）入門：Deep Insider Brief ― 技術の“今”にひと言コメント

AIコーディングにおける「ループ」には、エージェントが回す内側ループと、ハーネスが回す外側ループの2種類がある。両者の違いと外側ループがもたらす課題を、アルミン・ロナッハー氏の記事に沿って初心者向けに解説し、その「記憶」の扱いについての筆者の考えも添える。

» 2026年07月03日 05時00分公開

[一色政彦，デジタルアドバンテージ]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

連載目次

　ソフトウェアエンジニアの仕事は、「コードを書くこと」から「ループを書くこと」へと移っていく。AIコーディングの最前線では、そうした見方が語られ始めている。つまり、これからのソフトウェア開発を考える上で、ループエンジニアリングという考え方は避けて通れなくなってきた。ここで重要なのが、AIコーディングにおける「ループ（loop）」には、大きく2種類あるという視点だ。

　一つは「AIエージェントが回す内側ループ」であり、もう一つは「ハーネス（エージェントを動かす実行レイヤー）が回す外側ループ」である。この2つの違いと外側ループがもたらす課題、そしてソフトウェアエンジニアの未来の仕事について、アルミン・ロナッハー（Armin Ronacher）氏が「The Coming Loop（来たるべきループ）」と題したブログ記事で論じている。

「内側ループ（エージェントループ）」と「外側ループ（ハーネスループ）」のイメージ

　ロナッハー氏は、Web開発フレームワーク「Flask」の作者として知られるだけでなく、OSS（オープンソースソフトウェア）のAIコーディングエージェント「Pi（パイ）」を擁する企業Earendil（エアレンディル）の共同創業者の一人でもある。GitHub上の活動を見ると、Piの開発やレビューにも関わっていることが分かるため、AIコーディングに関する思想・開発・実体験に通じた、説得力の高い論者だと言える。

　同氏の説明に基づくと、まず内側ループとは、AIがツールを呼び出し、その結果を取り込み、ファイルを読み書きし、テストを実行する一連の反復を指す。AIエージェントが作業中に何度もツールを使い、結果を見て次の行動を決め、最後に「完了した」と告げるまでのループである。通常のAIエージェントもこのようなループを行うが、筆者の考えに基づけば、Claude CodeやOpenAI Codexの/goalコマンドなどもこの内側ループの一例と言える。

　次に外側ループとは、AIが「完了した」と言っても、ハーネスが「まだだ」と判断すれば、同じセッションを続けたり、新しい指示を差し込んだり、コンテキスト（AIが一度に扱える文脈情報）を入れ替えて別のセッションを立ち上げたり、別のマシンへ引き継いだりする仕組みのことだ。本来ならAIが「終わり」と言うはずの地点を越えて、作業を継続させたり、次の作業へつなげたりするためのループである。

――元記事が特に注目しているのは、この「外側ループ（ハーネスループ）」である。そこで筆者からも、外側ループを支える「記憶」や「タスクキュー」の考え方について、『Deep Insider Brief』恒例の“ひと言コメント”として考えを述べたい。その後で、記事の論点を順に整理していく。一見するとループエンジニアリングは万能の仕組みに思えるが、同氏は「私はこの働き方にまだ十分なじめていない」と率直な気持ちも明かしている。後半では、その違和感にも特に注目してほしい。

　Deep Insider編集長の一色です。こんにちは。

　今回の記事を読んで、個人的に一番面白いと思ったのは、「内側ループ」と「外側ループ」という区切り方です。皆さんは、すぐにイメージが湧いたでしょうか。以前に書いた「ループエンジニアリングとは」を解説した記事では、私自身がこの2つをまだ十分に分けて考えられていませんでした。

　ロナッハー氏の主張そのものではなく、あくまで私なりの理解に基づくと、「内側ループ」はAIエージェントの内側で回る処理です。特に大事なのは、最後に「完了しました」と止まるところです。もし永遠に止まらなかったら、困りますよね？（笑）

　一方、「外側ループ」はAIエージェントの外側で回る仕組みです。特に大事なのは、内側ループがいったん止まった後も、ハーネスが必要に応じて次の実行につなげられるところです。AIが「終わりました」と言っても、外側の仕組みが「いや、まだ続きがある」と判断できるわけですね。

　いずれにしても、内側と外側のループをきっちり分けて考えた方が、概念を理解しやすく、ループエンジニアリングにも取り組みやすいと感じました。それが、この記事を書いた理由です。

　私自身も、実装プランをPLAN.mdやTODO.mdのようなMarkdownファイルにまとめ、AIコーディングエージェントにチェックボックス形式で最後まで実行してもらうことがよくあります。これは実践としてかなり便利です。ただ、先ほどの整理に従えば、この段階ではまだ内側ループに近いのだと思います。AIが1つのセッションの中で計画を読み、実装し、テストし、完了報告するからです。外側の仕組みが次の実行を起動しているわけではありません。

　外側ループに近づけるには、チケットやIssue（イッシュー）とも呼ばれるタスク一覧が、「人間とAIが読むメモ」ではなく、「次の実行を起動するキュー」になる必要があります。未完了タスクを拾う。失敗した理由を残す。次のセッションに文脈を渡す。別のAIに検証させる。こうした仕組みが整って初めて、ハーネスループらしくなるのではないかと考えています。

　そこで今は、前の記事に登場した課題管理ツール「Linear」のIssueを、外側ループ用のタスクキュー兼記憶領域として使おうとしています。環境構築は完了して、あとは実践あるのみの状態です。ただし、まだ時間が取れず、実践できていません。しばらく実際に試して、うまくいった点や失敗した点が見えてきたら、あらためて別の記事としてまとめるつもりです。お楽しみに。

　ここからは、ロナッハー氏の論点を、できるだけ分かりやすく順に整理していこう。

ロナッハー氏がこの働き方にまだなじめていない理由

　ロナッハー氏は、自分が深く気にかけるコードについては、この働き方でうまくいった経験がまだほとんどない、と打ち明ける。出荷するコードは自分で理解していたい、という思いが強いからだ。今のAIモデルが書くコードには、次のような傾向があるという。

防御的過ぎる： あらゆる異常ケースに対して、その場その場の防御処理を追加しようとする
複雑すぎて視野が狭い： 強い不変条件（invariant：常にこうあるべきという前提）を立てず、「悪い状態をそもそも起こせなくする」代わりに、後付けの代替処理（フォールバック）を積み重ねる
構造を悪化させる： コードの重複や筋の悪い抽象化を生み、設計のあいまいさを、さらに仕組みを足して覆い隠す

　元記事では、アンドレイ・カルパシー（Andrej Karpathy）氏の発言として、AIは「例外を死ぬほど恐れている」という表現が紹介されている。本来あってはならない状態すら、わざわざ処理しようとするのだ。こうした性質をループに乗せると、1回ごとに小さな防御が積み重なり、システムは見た目こそ頑丈になるが、人間にはどんどん理解できなくなっていく。指針なくこの道具を新人に渡すと、悪い習慣まで教えてしまう、とロナッハー氏は警告する。

それでも、ループが目覚ましく機能する場面

　一方で、ループという手法がすでに見事に機能している領域があることも、ロナッハー氏は正直に認めている。元記事で挙げられた例は次の通りだ。

コードの移植： あるプログラミング言語から別の言語へ作り直す作業（Bunの一部をZig言語からRust言語へ移植する取り組みや、同氏自身によるテンプレートエンジン「MiniJinja」のGo言語への移植など）
性能改善の探索： AIが実験し、ベンチマーク（性能測定）し、失敗を捨て、より良い案を探し続ける
セキュリティスキャン： 脆弱性（ぜいじゃくせい：セキュリティ上の弱点）の洗い出し
調査・探索： 複雑な問題空間を調べ、結果を報告させる

　これらに共通するのは、新しく長く使うコードを生み出すのではなく、既存のコードを変換するか、初めから長持ちさせる必要のない成果物（試作や調査結果）を出すという点だ。ハーネスは「次の一歩に進んでよいか」の手がかりさえあれば回せる。その手がかりは厳密な合否判定でなくてもよく、別のAIに判定役／審判役を任せることもできる。

ソフトウェアが「機械」から「生き物」へ変わる

　ロナッハー氏が持ち出すのが、「ソフトウェアは機械から生き物（organism）へ変わりつつある」という比喩だ。

　かつてソフトウェアは、中身を1枚ずつはがして理解できる「決定論的な機械」（同じ入力なら必ず同じ結果になる仕組み）として捉えられてきた。だが今は、症状を観察し、仮説を立て、対処してまた観察する、医者が患者を診るような「生き物」として扱われ始めている。

　AIにコードを書かせるだけでなく、障害の診断や修正まで任せる現場も増えた。AIがログを読んで原因を推定し、修正案を出し、それを別のAIがレビューして、人間の監督なしにmainブランチ（公開・本番用の主軸となる版）へ反映する例すらある。便利ではあるが、それは「全体を理解しないまま運用する」ことを受け入れる選択でもある、とロナッハー氏は言う。

ループを使わなくても「降りられない」

　居心地が悪いのは、この「機械任せの未来」から完全に降りることはできない、という点だ。

セキュリティ： 自分がループを使わなくても、攻撃者やセキュリティ研究者は機械を回し続ける。その結果、報告が洪水のように押し寄せる。実際、コマンドラインツール「curl」の開発者であるダニエル・ステンバーグ（Daniel Stenberg）氏の投稿がその例として挙げられており、いまやメンテナーたちは、AI生成のものが大半を占める報告に圧倒されているという。守る側も、せめて選別や再現のために機械を使わざるを得なくなる
競争： 一部のチームは圧倒的な速度で開発を進める。かつて50人かかった仕事を5人でこなし、「あの製品みたいに作って」と機械に命じることすらできる。ユーザーが満足するなら、それで十分ではないか、という声も出てくる

そして生まれる、新たな「依存」

　ロナッハー氏が最も恐れるのは、私たちがこうした機械に新しい形で依存することだ。

　道具への依存自体は昔からあった。だが、かつてコンパイラ（プログラムを変換するソフト）を一度買えば済んだのと違い、強力なAIは継続的なコストであり、しかも認知的な依存でもある。コードを書くのも、レビューも、修正も、保守もループ任せになったとき、もし同じ性能のAIが使えなくなったらどうなるのか。例えば輸出規制で最強のモデルへのアクセスが断たれたら。コストが払えなくなったら。あるいは、チームが機械なしではコードを理解する力そのものを失ってしまったら。

　すでに、人間だけでは保守しづらく、機械の参加を前提とするコードベースが生まれ始めている。中身を完全には説明できないまま変更を取り込む人、AIに言い換えてもらわないと不具合報告や議論の文章すら書けない人も増えている、とロナッハー氏は指摘する。