今回の記事サマリー
はじめに
「ループエンジニアリング」という言葉が、AIエージェント界隈で急速に広まっています。よく引かれるのが Addy Osmani 氏のこの一文です。
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
（ループエンジニアリングとは、「エージェントにプロンプトを打つ人」を自分がやめること。代わりにそれをやるシステムを設計することだ）
ただ、この文脈で語られる実践例は、テストの自動修正、CI、コードレビューなど、ほぼすべてが「開発」の話です。
私は現在の会社で経営メンバーの一人としてマネジメントに携わっています。弊社は「AIと働く」をテーマに掲げていて、開発の現場だけでなく経営管理のあらゆるタスクをAIエージェントと回しています。経営メンバー4人が1つのGitリポジトリを共有し、Claude Code から売上集計・議事録蓄積・案件パイプライン管理を行う運用です。
実はこの環境、ループエンジニアリングという言葉が広まるより前から、日々の必要に迫られて少しずつ作ってきたものです。ただ、後からこの概念に出会って照らし合わせてみると、知らないうちに沿っていた部分と明確に欠けていた部分の両方が見えました。この記事では、その突き合わせで何が分かったか——先にできていたこと、これから取り組むべきこと、そして経営タスクの何をループに渡すべきでないか——を書きます。
ループエンジニアリングとは（超要約）
プロンプトの書き方でも、コンテキストの整え方でもなく、その上の層の話です。
完全なループは5つの動作を備えます。Trigger（スケジュール等で勝手に起動する）、Discovery（自分で仕事を見つける）、Execution（実行する）、Verification（結果を機械的に検証する）、Memory（状態を会話の外に永続化する）。
このうち心臓部は Verification です。「速く動くループ」より**「正しく止まるループ」**を作るほうが難しく、重要——これが後半の伏線になります。
ハーネス編: 会社の状態をMarkdownで持つ
ループの話の前に、その土台の話をさせてください。実は一番効いているのはここです。
経営管理リポジトリには、経営会議のレポート、チーム定例の議事録と文字起こし、メンバーの稼働状況、人事評価の記録が、すべてMarkdownとして年度・月別に格納されています。つまり「会社のいまの状態」が、AIがそのまま読めるプレーンテキストとしてGit管理下に存在します。
その上に、スラッシュコマンド（カスタムスキル）が約20本。クラウド型の請求・販売管理SaaS、ビジネスチャット、プロジェクト管理ツールとAPI連携し、たとえばこんなことが一発でできます。
-
/pl 今月— 売上・粗利・営業利益の予実を確度別に集計 -
/pipeline— 2週間動きのない見込み案件を洗い出し - 議事録取込 — Web会議ツールの自動文字起こしを整形してリポジトリへ保存
ポイントは、エンジニアでないメンバーも使えることです。セットアップを1回実行すれば、あとはチャット欄にコマンドを打つだけ。レポートは会議後にコミットされ、git pull すれば全員の手元とAIに最新の状態が届く——エンジニアには当たり前のワークフローを、経営情報の流通経路にそのまま使っています。
「AIが読める形で会社の状態が存在し、誰でも同じコマンドで触れる」——ここまでがハーネスで、ループはこの上に載ります。
データの扱いについて
この仕組みで扱っているのは自社の経営データ（受発注・会議記録・稼働）で、顧客からお預かりしたデータや成果物はこのリポジトリには置いていません。AIの利用は入力が学習に使われない法人向けの契約形態に限定し、リポジトリへのアクセスも経営メンバーのみに絞っています。本記事の事例は、実在の顧客や数値が特定されない形に加工しています。
ループ編: 無人で回っているもの
代表的なものを4本紹介します。どれもループエンジニアリングという言葉を知って作ったものではなく、運用の困りごとを1つずつ潰していったら、結果的にこの形になっていたものです。共通するのは「会議やチャットという人間側の締め切りに、AIの出力を先回りさせる」という構図でした。
1. 週次営業会議のアジェンダを、会議前に自動生成する
毎週金曜の営業会議に向けて走るループです。販売管理SaaSから今月・来月・再来月・年間の売上／粗利／営業利益を取得し、予算と突き合わせて達成率とギャップを算出。さらにオファリング別・案件区分別の粗利内訳まで分解し、整形したシートを新規作成します。
面白いのは、成果物がそのまま会議のアジェンダになる点です。「資料を作る」のではなく「議題を生成している」ので、会議のための準備時間がゼロになります。
出力は3部構成になっています。
- 数字確認 — 予実の達成率・ギャップと、そこに添えるAIコメント
- 未更新案件チェック — 見込み案件のうち、2週間以上動きのないものを抽出
- 前回アクションの引き継ぎ — 前週シートの未完了アクションを今週シートの冒頭に転記
3つ目が地味に効いています。「先週決めたことが今週の議題の一番上に必ず載る」状態を機械的に作ると、アクションが立ち消えになりません。ループが会議の記憶を担当している格好です。2つ目の未更新チェックも、人間がやると気まずいが機械なら角が立たない種類の仕事で、「2週間動いていません」という指摘を誰の主観でもなく更新日時という事実から出せます。
2. 経営会議レポートを、規定フォーマットで自動作成する
週2回の経営会議の前に走ります。年度・今月・来月の売上／粗利／営業利益を確定ベースで集計し、予算と比較。加えて、見込み案件を確度別（高／高中／高中低）に積み上げた営業利益の3段階シミュレーションまで作って、規定のMarkdownテンプレートに流し込みます。これも生成物がそのまま会議アジェンダです。
気に入っているのは、AIが触る範囲と人間が書く範囲がテンプレート上で分かれていることです。数値・達成率・見込み計算は自動入力。一方で経営レポートサマリや担当者別報告といった判断や文脈が要るセクションは、テンプレートのまま残すよう指示してあります。
つまりレポートは常に「数字は埋まっていて、判断は空欄」で出てきます。人間は空欄だけ埋めればいい。この線引きが、後半の「何をループに渡さないか」の実装そのものです。
3. チームの稼働状況を集計し、ドキュメントDBとチャットに配信する
プロジェクト管理ツールから今月・翌月のタスクを担当者別に集計し、稼働レポートを生成するループです。このループは出口が3つあるのが特徴です。
- Markdownファイルとしてリポジトリに保存（後から検索・比較できる資産）
- ドキュメントDB（Notion）に1ページとして書き込み（日付降順で並ぶので最新が常に先頭）
- チャットの指定ルームにサマリーを投稿（人が能動的に見に行かなくても届く）
冗長に見えますが、それぞれ読者と用途が違います。リポジトリはAIと過去比較、ドキュメントDBは他部署の閲覧、チャットは「気づいてもらう」ため。ループの価値は生成より配信先の設計にあると考えています。
このループの目的は進捗の監視ではなく、負荷の偏りを早く見つけて仕事を配り直すことです。特定の人にタスクが寄っているのは、たいてい本人が言い出す前に数字に出ます。集計では月間の標準的な稼働時間に対する割合で各メンバーの負荷を段階評価し、余裕のある人と手一杯の人を並べて見えるようにしています。
加えて「予定時間が未設定のタスク」を警告として出しています。これはデータの欠損を検知する仕組みで、集計値だけ見て「まだ余裕がある」と誤読する罠を潰すためです。実際には見積もり時間が入っていないだけ、というケースが一番危ない。
チャット投稿には数字の羅列ではなく「Aさんは来週から手が空くので、詰まっている案件を寄せられそう」といった、次の打ち手につながる注目点を添えます。まさにLLMが得意な仕事です。
4. 定例の文字起こしから、議事録とナレッジとヒヤリハットを生成する
個人的に一番「AIらしい」と思っているループです。週2回のチーム定例で、Web会議ツールが吐いた生の文字起こしから3種類の成果物を作ります。
(a) 議事録 — 文字起こしを整形し、概要・次のステップ（担当者つきアクション）・トピック別の議論内容に構造化します。
(b) ナレッジ — ここからが本題です。会話の中から「他メンバーが後から参照する価値のある知見」だけを検出し、別ファイルに切り出します。判定基準はリポジトリ内に文書化してあり、AIはそれを読んでから抽出します。基準の核はこの一文です。
「半年後・1年後にこの内容を見返すメンバーがいるか？」を問う。Yes ならナレッジ。
同時に「含めないもの」も明記しています。単なる進捗報告、スケジュール調整、雑談、横展開できない作業詳細。除外基準のほうが包含基準よりずっと重要でした。これがないと会話のすべてを「知見」として拾ってしまい、誰も読まないファイルが量産されます。
(c) ヒヤリハット — 同じ文字起こしから、今度は「危なかった話」を検出します。ナレッジが「うまくいった知見」を拾うのに対し、こちらは事故には至らなかったものの再発防止の価値がある事象を拾う担当です。検出したものは影響度で3段階に分類して記録します。
これは心理的安全性の観点でも効いていると感じます。「報告してください」と言われると身構えますが、定例で自然に出た話がAIに淡々と記録されるだけなら、誰も咎められている感じがしません。人間が集める運用よりうまく機能している実感があります。
そして毎週月曜、先週分のナレッジとヒヤリハットを要約してチャットに配信します。要約のルールも決めてあり、ナレッジは1〜2文、ヒヤリハットは「事象 → 再発防止」に圧縮。該当が0件でも「（0件）」と明記してセクションを残す——沈黙と「該当なし」を区別するためです。前者はループの故障を意味しますが、後者は正常な結果です。
このループの信頼性を支えているのは、賢いリトライ処理ではなく再実行しても安全な設計です。「すでにファイルがある日はスキップ」という冪等性があるので何度動かしても壊れず、ある日の実行が失敗しても、期間をまとめて走査する次の実行が欠損を埋めます。エラーハンドリングを作り込むより、ずっと安上がりでした。
これらは全体のごく一部です
ここに挙げた4本は一部にすぎません。スキル自体は約20本あり、稼働の度合いも完成度もバラバラです。
そしてどれも「作って終わり」にはなっていません。集計の対象期間がずれていた、要約が冗長すぎた、チャットの体裁が読みにくかった——使うたびに不満が出て、その都度Markdownを直す。プロンプトを直すというより業務マニュアルを改訂している感覚に近い。これは「メタループ」と呼ばれるもの——ループ自体を改善するループ——にあたりますが、まだ計測ではなく体感ベースの改善に留まっているのが正直なところです。
やってよかったこと
会議の準備という仕事が消えました。 週次営業会議も経営会議も、始まる時点でアジェンダが出来上がっています。数字を集めて資料に清書する作業が丸ごとなくなり、参加者は最初から議論に入れます。
「人間がcronの代わりをする仕事」が消えました。 以前は「定例が終わったら議事録を取り込む」といった、決まったタイミングで決まったコマンドを打つ係がいました。これは人間がTriggerを人力代行していただけで、真っ先に自動化すべきはここでした。
「後で書こう」が消えました。 ナレッジ共有もヒヤリハット報告も、人間の善意と記憶力に頼ると必ず摩耗します。定例で口頭で流れた話をAIが拾って記録するようにしてから、蓄積が止まらなくなりました。人間に新しい作業を課さずに、情報だけが溜まる構造にできたのが大きいです。
状態がファイルに外部化されていると、AIの事故に強い。 コンテキストが飛んでも会話が途切れても、リポジトリのファイルツリーが「どこまで処理したか」を表しているので何も失われません。再実行すれば続きから回ります。
照合系のタスクがAIと相性抜群でした。 2つのシステムのデータ突合や、ステータスの整合性チェック。「突き合わせてズレを報告する」仕事は検証可能性が高く、安心して任せられます。
オンボーディングが人間にもAIにも安くなりました。 リポジトリ直下の AGENTS.md に運用ルールを集約してあり、AIは毎セッションこれを読んでから動きます。組織のルールがドキュメントではなく実行環境に埋め込まれている状態です。新しいメンバーが増えても、新しいAIモデルに乗り換えても、渡すものは同じリポジトリひとつ。
会議の議論が「数字の確認」から「判断」に寄った実感もあります。
自己監査で見つかった穴
ここからが本題かもしれません。言葉を知る前から回していたループを、後から来た概念で採点したらどうなるか。ループエンジニアリングの考え方を整理した資料を渡してAI自身に監査させたところ、痛いところを突かれました。
Triggerを自動化しただけでは、ループではなかった。 5つの動作のうち、うちにあったのは Trigger・Discovery・Memory まで。心臓部の Verification——出力を機械的に検証する層と、失敗を人間に届ける経路——がすっぽり抜けていました。スプレッドシートやドキュメントDB、チャットに無人で書き込むループが、書き込んだ結果を誰も検算していない状態で動いていたわけです。
たとえば集計値が元データの読み取りミスでずれていても、レポートは何食わぬ顔で生成されます。「数字が入っている」ことと「数字が正しい」ことは別なのに、後者を確かめる仕組みがない。会議アジェンダを自動生成するループにとって、これはかなり際どい欠落でした。
いま補っているのがここで、生成した数値を元データと突合する検算を入れています（後述）。同時に運用の歯止めとして、自動生成された数字は人の最終確認を通してから社外に出すという線を引きました。ループを止めずに穴を塞ぐには、機械的な検証と人間のゲートを両方かける時期が要ります。
さらに言えば、いま一番怖いのは「AIが変なデータを書くこと」ではなく、**「ループが静かに死ぬこと」**だと気づきました。認証トークンの期限切れなどでループが止まっても、いまの構成では誰にも通知が飛びません。止まったことに2週間気づかない、が現実的な事故シナリオです。
もうひとつ面白い発見がありました。監査の過程で、AIは自動化済みの運用を「手動運用」と誤認して改善提案をしてきたのです。自動化の実態がコードからは見えず、人間の頭の中と各マシンのcron設定にしかなかったから。作った本人すら把握できていない資産が増えることを Comprehension Debt（理解の負債） と呼びますが、これは人間だけでなくAIにも起きる。対策は地味で、「何が・どこで・いつ動いているか」の台帳を1枚書くだけで両方の認識が揃います。
結局のところ、無人で動くループは、ミスも無人でし続けるわけです。耳が痛い。
経営タスクの何を渡し、何を渡さないか
ループに向くのは「繰り返し発生し、機械的に検証でき、境界が明確」なタスクです。経営管理で言えば、取込・転記・照合・差分検知。ここは積極的に渡します。
一方で、経営判断そのもの、戦略サマリの質、人事評価の評点は渡しません。「合格」を検証関数に翻訳できないからです。検証できないゴールを渡すと、エージェントは"もっともらしく見える出力"に収束します。スロップファクトリー（眠っている間に動くゴミの量産工場）と呼ばれる状態です。
人事評価が良い例で、データ収集・整形・過年度比較まではAIが行いますが、評点を付けるのは人間です。この線引きは効率ではなく検証可能性の問題として引いています。
これからやること
- 数値の検算（最優先・着手済み）: 出力した集計値を元データと突合し、合わなければ人に上げて止める。前回値との差分が閾値を超えたら警告する、といった機械的なチェックから入れる
- 死活通知: 各ループの失敗時だけチャットに一報（成功時は沈黙でいい)
- 自動化の台帳: 何が・どこで・いつ動くかを1ファイルに
- L1から積む新ループ: 会議前に差分と未更新案件のブリーフを自動投稿する「読むだけ」のレポートループ。自律度は L1（報告のみ）→ L2（人間承認つき）→ L3（無人）と段階を踏み、いきなり無人化しない
おわりに
やってみて思うのは、ループエンジニアリングは技術というより組織設計だということです。逐一マイクロマネジメントする代わりに、目標とレビュー体制と引き継ぎを整えて「自分が口を出さなくても回る状態」を作る——AIエージェントに対してやることも、それとまったく同じでした。
概念が後から来たことにも意味がありました。先に手を動かしていた身からすると、名前がつくことの価値は「真似る対象ができること」ではなく、自分たちの現在地を測る物差しができることです。物差しを当てたから、どこが本質的にできていて、どこが欠けているのか（うちの場合は検証でした）を言語化できました。同じように「気づいたら自動化がいくつか動いている」状態の方は、概念に照らして採点してみてください。合っていた部分は自信になり、欠けていた部分は次の課題リストになります。
そしてこれは、経営陣が自分でやってみないと設計できない類のものだと思います。経営がAIネイティブであれば、現場のAI活用に天井はなくなります。「AIと働く」を掲げる会社の経営管理の裏側として、どなたかの参考になれば幸いです。
参考: Addy Osmani "Loop Engineering" (2026)、Peter Steinberger 氏の一連の提唱
関連