会社の強さは、ループの設計で決まる
最近、AIを使ったソフトウェア開発の文脈で、「ループエンジニアリング」という言葉が広がっています。
当然ですが、これはわたしが勝手に付けた名前ではありません。IBMも2026年7月、AIエージェントが目標に向かって行動し、結果を観測し、判断を変えながら反復する仕組みを設計する、新しいエージェント開発の実践として整理しています。
プロンプトを一回うまく書く話ではなく、AIに何を任せるか。どの情報を渡すか。何をもって正しいと判断するか。失敗したらどこへ戻すか。いつ止めるか。人が一手ずつ指示する代わりに、AIが仕事を進めるループそのものを設計するみたいな感じです。
今の開発会社の強さは、単にコードを速く書けるかではなく、このループをどこまで設計できるかで決まり始めていると思います。
そして、ここから考えると、これは開発だけの話ではありません。
経営も、マーケティングも、営業も、採用も、結果を観測して次の判断を変えるサイクルで動いています。
会社の強さは、そのループをどれだけうまく設計できるかで決まる。今回はその話です。
AI開発は、プロンプトからループの設計へ移っている
プロンプトエンジニアリングは、一回の指示をどう良くするかという話です。
コンテキストエンジニアリングは、その判断に必要な情報をどう渡すか。ハーネスエンジニアリングは、AIの周りにどんな道具、権限、実行環境、検証手段を置くか。
ループエンジニアリングは、その外側にあります。
一回動いた後に何を観測するのか。結果が悪ければ何を変えるのか。もう一度実行するのか、人に戻すのか、そこで止めるのか。得た情報を次の実行へどう残すのか。
プロンプト、コンテキスト、ハーネスを一回の実行で終わらせず、時間の中で回り続ける仕組みにする。
そのためには、少なくとも次の要素が必要になります。
目標、現在の状態、使える道具、検証方法、失敗したときの戻り先、停止条件、次回へ残す記録。
AIが賢くなるほど、人間が毎回細かく指示する必要は減ります。その代わり、何を目指し、何を見て、どこまで自動で進めてよいかを設計する責任は重くなる。
良い開発会社は、三つのループをつなげられる
開発のループは、一つではありません。実務では、少なくとも三つに分けて考えた方が分かりやすい。
一つ目は、実装のループです。
AIエージェントがコードを書く。テストやビルドを実行する。失敗を読み、修正し、もう一度試す。これは秒から分、長くても数時間で回る内側のループです。
二つ目は、開発判断のループです。
作られたものを人間が確認する。要求や設計とずれていれば、コードだけではなく、仕様や優先順位まで戻して考える。これは数時間から数日で回ります。
三つ目は、顧客と事業のループです。
実際に使ってもらい、利用状況、問い合わせ、離脱、売上、現場の反応を見る。そこで分かったことを、次の要求や商品設計へ戻す。これは数日から数か月で回る外側のループです。
内側の実装ループだけを速くしても、外側の判断が間違っていれば、求められていないものを早く作るだけです。
反対に、顧客の声を集めても、要求へ戻す経路がなく、実装と検証までつながらなければ改善は進みません。
今の良い開発会社は、AIでコードを速く書ける会社というだけではない。
顧客の反応が要求へ戻り、要求が具体的な実装へ落ち、実装結果がテストや画面などの証拠とともに戻る。この一連のループまで設計できる会社だと思います。
これは、経営もマーケティングも営業も同じ
この構造は、開発に限った話ではありません。
マーケティングなら、記事を出してアクセスを見るだけではループが閉じていません。
どの記事から問い合わせが生まれたのか。どんな会社が商談へ進んだのか。受注したのか、失注したのか。その結果が、次に狙う顧客や発信内容へ戻って初めて、マーケティングが学習します。
営業も同じです。
商談をして、提案して、受注か失注かを見る。失注理由が営業担当者の記憶に残るだけでは、会社は変わりません。
価格が合わなかったのか。商品が合わなかったのか。狙う顧客が違ったのか。説明の仕方が悪かったのか。その情報が商品、価格、提案、マーケティングへ戻る必要があります。
経営なら、資金や人を配分し、その結果として売上、利益、現金、顧客の反応を見る。そして次の配分を変える。
採用なら、人を採り、仕事を任せ、成果や詰まり方を見て、採用基準、教育、権限、役割設計へ戻す。
どれも、行動して結果を見るだけでは足りません。結果によって次の判断が変わるところまでつながって、初めてループになります。
会社は「計画」の工程を作るけど、「実行から戻す」経路を作っていない
多くの会社は、仕事を前へ進める工程をかなり細かく設計しています。
誰が提案書を作るのか。誰が確認するのか。いつまでに納品するのか。どこで承認を取るのか。
でも、その結果をどこへ戻すのかは、あまり決まっていません。
納品後に分かった顧客の不満は、次の商品設計まで戻っているのか。
営業が聞いた失注理由は、次の提案だけではなく、価格や商品、発信内容まで戻っているのか。
問い合わせの質は、次の記事や広告へ反映されているのか。
開発中に見つかった仕様の矛盾は、その場の修正で終わらず、要求や判断基準まで戻っているのか。
会社は「行き」の工程を作るのは得意です。でも、「戻り」の経路は自然発生に任せていることが多い。何となく終わったねーがほとんどです。
だから、同じ失注を繰り返す。同じ事故がまた起きる。同じ会議で同じ反省をする。
振り返ってはいる。でも、次の判断が変わっていない。
それならループは回っていません。ただ元の場所に戻っているだけです。
あと、よくあるのが振り返るものの仕組みに反映されていないとかですね。
ループは、回っていれば良いわけではない
ループ自体は、放っておいてもできます。
たとえば、記事のアクセス数だけを追う。アクセスが増えた記事に似た記事を書く。さらにアクセスが増える。
ループは回っています。
でも、問い合わせや受注が増えていなければ、会社が強くなったわけではありません。アクセスを増やす能力だけが強くなっています。
営業でも、商談数だけを追えば、受注しにくい顧客との商談を大量に作る仕組みが完成するかもしれません。
開発でも、機能数だけを追えば、誰も使わない機能を高速で増やせます。
売上だけを追えば、受注するほど利益や現金が減る案件を増やす可能性もあります。
ループは、正しいものだけを強化するわけではない。間違った目標や判断も、回すほど強くします。
だから、速く回す前に、何を良い結果として扱うのかを決めないといけません。
良いループを作るための六つの問い
会社の仕組みとしてループを成立させるなら、最低でも六つを決める必要があります。
- 何を目標にするのか。
アクセス、問い合わせ、受注、利益、継続利用など、目標によって強化される行動が変わります。 - 何を観測するのか。
結果を判断するための数字、顧客の声、テスト結果、画面、ログなどを決めます。観測できなければ、ループは現実から学べません。 - 何と比較して良し悪しを決めるのか。
目標、過去、顧客の期待、受け入れ条件など、判定基準が必要です。 - 結果をどこまで戻すのか。
その場の修正で終えるのか、手順、仕様、商品、価格、狙う市場まで見直すのか。戻す深さで改善の大きさが変わります。 - 誰が次の行動を変えるのか。
会議で話して終わらせず、判断し、実際に変更する責任者を決めます。 - 学びを何に残すのか。
個人の記憶ではなく、判断基準、仕様、手順、商品、教育内容、システムなど、次の人と次の実行が使える形にします。
ループエンジニアリングとは、行動を繰り返すことではなく、現実から得た結果が次の判断と仕組みの変更へ戻る経路を設計することです。
AIによって、改善のサイクル自体を仕組みにできるようになった
これまで、会社のループの多くは人間の頭や会議の中にありました。
現場で何かが起きる。担当者が覚えている。会議で話す。誰かが判断する。次の仕事で思い出せれば反映する。
かなり人に依存しています。
生成AIを使うと、状況を観測し、目標との差を見つけ、次の行動を提案し、実行し、結果を確認し、その証拠と学びを残すところまで仕組みにできるようになってきました。
ここで重要になるのがデータです。
データは報告書を作るためだけのものではありません。ループが現実を観測するためのセンサーです。何が起きたかを取れなければ、AIも人間も次の判断を変えられません。
自分たちで開発しているPM on Railsでも、作りたいものを整理し、具体的な利用場面へ落とし、実装し、試し、証拠を残し、そこで分かった差を上流へ返す流れを作ろうとしています。
ただし、下流で分かったことが自動的に正式な要求を書き換えるわけではありません。
証拠付きの変更案として戻し、人間が正式に変えるかを判断する。
戻り道は作る。でも、勝手に逆流はさせない。
AIが自律的に動くほど、何を観測し、何を正解とし、どこまで自動で変えてよいかというループの設計が重要になります。
経営者の仕事は、ループ同士をつなぐこと
会社には、異なる速度で回るループがあります。
日々の作業は一日単位。開発は数時間から数週間。営業やマーケティングは数週間から数か月。採用や組織づくりは数か月から数年。事業や資本の配分は、さらに長い時間で判断します。
問題は、それぞれが別々に回ることです。
開発だけが速くなり、顧客から学ぶ速度が遅ければ、求められていないものを高速で作ります。
マーケティングがアクセスだけを見て、営業結果が戻らなければ、問い合わせにつながらない発信が増えます。
営業が売上だけを見て、開発負荷や利益が戻らなければ、取るほど会社が苦しくなる案件が増えます。
だから経営者の仕事は、各部署に目標を渡すだけでは足りません。
市場から得た情報を商品へ戻す。商品の利用結果を営業へ戻す。営業結果をマーケティングへ戻す。開発負荷と利益を価格や受注判断へ戻す。現金の状態を次の投資判断へ戻す。
個々の問題を自分で解き続けるより、この接続を作る方が会社に残ります。
各ループがつながって、初めて会社全体が学習します。
会社の強さは、答えを更新する仕組みで決まる
ループエンジニアリングという言葉は、今は主にAI開発の文脈で使われています。
でも、その本質を一段広げると、会社全体にも同じことが言えます。
最初から正しい商品を作れる会社はありません。最初から正しい市場を選び、正しい営業方法を使い、正しい人を採り続ける経営者もいないと思います。
だから重要なのは、間違えないことではない。
間違ったときに気づけるか。原因がある場所まで戻れるか。次の行動を変えられるか。その学びを会社に残せるか。
一つの優れた商品を持っている会社より、顧客から学び、優れた商品を繰り返し作れる会社の方が強い。
一人の優秀な営業がいる会社より、失注から学び、営業全体と商品を変えられる会社の方が強い。
AIでコードを速く書ける開発会社より、要求、実装、検証、顧客の反応を一つのループとして設計できる開発会社の方が強い。
強い会社とは、正解を知っている会社ではなく、現実から学び、次の判断を変え、その学びを仕組みに残せる会社です。
結局、会社の強さは、今持っている答えではなく、答えを更新し続けるループで決まるんだと思います。