PDCAはもう古い？ Loop Engineeringを経営者の言葉で｜AI時代の社長の新しい仕事

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。

「PDCAって、なんか回ってる感じがしないんだよな」

そう感じたこと、ないですか。計画して、実行して、振り返って、改善して……でも現場はずっとバタバタのまま。AIを使い始めたら、今度は「AIに何をさせればいいのか」がわからなくなった、という経営者の方も多いです。

正直、私もずっとそこで詰まっていました。

ところが最近、海外のエンジニアたちの間で「Loop Engineering（ループエンジニアリング）」という考え方が話題になっています。提唱したのはGoogleのエンジニアリングマネージャーのAddy Osmaniと、エンジニアのPeter Steinberger。もともとはAI開発の現場から生まれた言葉なんですが、読んでいて私は「あ、これ、経営の話だ」とピンときました。

PDCAが「1周ずつ、人間が手で回す」ものだとしたら、Loop Engineeringは「何重にも入れ子になったループを自動で回し続けて、しかもそのループ自体がだんだん上達していく」という設計の思想なんですよね。

今日はこの5つの核心概念を、経営者の言葉に翻訳しながらお伝えします。技術の話としてではなく、「社長の仕事の定義」が変わる話として読んでください。

私自身、AIチームを動かしながら何度も転んで、その中でようやく腹に落ちた話でもあります。

PDCAの何が限界なのか

まず「なぜ今さらPDCAを疑うのか」を整理しておきます。

PDCAは優れたフレームワークです。ただ、前提として「人間が1サイクルを担当する」という設計なんですよね。計画も実行も確認も改善も、人間の判断と手作業が入る前提になっている。

ここにAIが加わると、この前提が崩れます。AIは1日に何百回も「実行」できる。人間が回せるサイクル数とは桁が違うんです。このスピードに対応するには、「人間が回す」から「人間がループを設計して、AIと組織が回し続ける」へ、仕組みごと変える必要がある。

これがLoop Engineeringの出発点です。

私がこの感覚を一番強烈に味わったのは、実はがんで入院していたときでした。

私が朝のLIVE配信を毎日続けていた時期に、がんで入院して、強制的に配信を中断したことがあったんです。仲間が代わりに続けてくれて。病室のスマホ越しにその光景を見たとき、震えました。「俺がいなくても、この”場”は続くんだ」って。

これは「人間が回す」前提が崩れた瞬間でした。最初は正直、複雑な気持ちもありました。でも結果的にその仲間も成長して、番組はもっと良くなって、私の負担も減った。「手放したら、全部良くなった」を身体で知った原体験です。

ループの設計って、つまり「自分が倒れても回る仕組み」を先に作っておく、という話なんですよね。

概念①「今の仕事」と「仕組み全体を見る仕事」を分ける

原文では「Inner Loop（内側のループ）」と「Outer Loop（外側のループ）」という言葉が使われています。

Inner Loop（内側のループ）＝今この瞬間の作業を、確実に終わらせる動きです。記事を1本書く、メールに返信する、数字を確認する。具体的で、完結した仕事ですね。

Outer Loop（外側のループ）＝複数の仕事を束ねて監督して、全体のサイクルを設計する動きです。「どのタスクを、どの順番でAIに渡すか」「どこで人間の確認を入れるか」「進捗をどう見るか」を決める役割。

日本語の経営の言葉で言うと、Inner Loopが「実務担当者の動き」で、Outer Loopが「社長・マネージャーの動き」に近いです。

ここで、私自身の話をさせてください。

私はCliftonStrengths（強みの診断）で、実行系の資質がほぼ全部、最弱圏に固まっているんです。コツコツ自分の手を動かして最後までやり切る力が、もともと弱い。Top10の中で実行系はたった1つだけでした。

私は長いあいだ、「自分で全部やり切れない」ことをコンプレックスに感じていました。でも、ある時ふと気づいたんです。実行が苦手なんじゃなくて、私はそもそも「実務担当者（Inner Loop）」に向いてないんだ、って。

視点を変えると、こういう構造なんですよね。Inner Loop（個別の実務）は苦手だから、Outer Loop（全体設計）に徹するしかなかった。だから私は、自分のAIチームを「実行は私がやらない。AIと仕組みに渡す。私は設計と監督だけをやる」という方針で組み立ててきました。

これは逃げじゃないんです。自分の弱みを認めたうえで、強みが活きる場所に陣取った、という分業なんですよね。実行力が弱いなら、実行が自動で回る仕組みを作ればいい。

Loop Engineeringは、この分業を「あえて設計しなさい」と明文化してくれた考え方でした。社長が全部やろうとするんじゃなくて、社長はOuter Loopの設計者に徹する。これが、AIを使う時代の経営者のポジションなんじゃないかなと思っています。

概念②「ツール」より「治具」を作れ

原文では「Harness is the Product（ハーネスこそが製品の本体）」という表現が出てきます。

「ハーネス」は、日本語で言うと治具（じぐ）に近いです。治具というのは、工場なんかで部品を正確な位置に固定したり、加工の精度を保ったりするための器具のこと。治具があると、誰がやっても同じ品質の製品が出てくるんですよね。

AIの文脈では「治具＝AIを動かすための枠組み・指示の構造・フロー」のことだと考えてください。

「いい指示を毎回ひねり出す」んじゃなくて、「どんなインプットが来ても、一定の品質でアウトプットが出る仕組みを作る」。この仕組みそのものが製品だ、というのがHarness is the Productの主張です。

実はこれ、AIチームの運用を手伝ってもらっている秘書のAIから、面と向かって言われたことがあります。

「思想はAIに効きません。構造は超効きます」——正直、最初は少しムッとしたんです。私は自分の想いや哲学を語ることで、AIの出力が変わることを期待していました。「私はこういう考え方を大切にしている」っていくら丁寧に話しても、出力はほとんど変わらない。これは地味にショックでした。

でも、指摘は正しかったんですよね。「このインプットが来たら、このステップを踏んで、このフォーマットで出してほしい」という構造を渡した途端、出力が大きく変わったんです。効いたのは想いじゃなくて、構造の設計のほうでした。

ただ、誤解してほしくないのは、「だから魂はいらない」という話ではないんです。むしろ逆で。魂（思想）はそのまま語ってもAIには効かない。でも、魂を「構造」に翻訳して渡すと、ものすごく効く。Harness is the Productというのは、まさにこの感覚です。「想いを語る人」より「魂を治具に落とし込める人」が、AI時代の経営者に求められている姿勢なんだと思います。

たとえば、毎月同じ品質でニュースレターを出したいなら。毎月うんうん唸って指示を考えるんじゃなくて、「どんな月でも、この品質で出力できる治具」を一度作り込む。あとはその治具を磨くことに時間を使う。

これがLoop Engineeringが示す、経営者の時間の使い方なんですよね。

概念③「失敗タスク」を自動で差し戻す仕組み

原文の3つ目の概念は「検証者にエンジニアリングを集中させる」という考え方です。

もう少しかみ砕くと、AIが仕事をした後、その結果が一定の品質水準を満たしているかを自動で判定する「確認役」を作り込む、ということです。水準を満たしたものだけが次のステップへ進んで、満たさなかったものは自動で差し戻される。

これを経営の言葉に翻訳すると、「品質ゲート付きの自動審査フロー」です。

昔のものづくり現場で言えば、出来上がった部品が規格を外れていたら自動ではじかれる、ライン検査の機能ですね。人間が1個1個チェックするんじゃなくて、仕組みが自動で良否を判定する。

この「確認役を作り込む」を、私のAIチームでは実際にやっています。正直に言うと、これは私が一から設計したものじゃなくて、コンサルの場で「Claudeの一発出しに頼らず、別のAIに評価・ファクトチェックをさせる多層構造にした方がいい」という話になり、秘書のAIチームが実装してくれた仕組みです。

AI特有の浅さとか、冗長な癖とか、上から目線の表現って、別のAIに相互監視させると構造的に排除できるんです。1つのAIに任せきりにしないで、AI同士で味見させる——これが効くという話を、AIチームから聞いた時は「なるほど」と素直に思いました。

自分で全部設計しなくていいんです。「こういう仕組みにした方がいい」と判断して、実装は任せる。それも社長の仕事だと思っています。

なぜここまでやるか。AIを使った業務で一番失敗しやすいのが、「AIが出したアウトプットを、そのまま使ってしまう」ことだからです。AIの出力は時々間違えるし、適切でない表現が混ざることもある。これを人間が毎回チェックしていたら、AIを使う意味の半分が薄れてしまうんですよね。

営業の現場なら、「AIが書いた提案文が、一定の長さと構成を満たしているか」「禁止ワードが含まれていないか」を自動でチェックする仕組み。コンテンツ制作なら、「事実確認が必要な固有名詞が含まれていないか」に自動でフラグを立てる仕組み。

社長の仕事は「毎回確認すること」じゃなくて、「品質ゲートを設計すること」なんです。

概念④ 暴走を止める「停止条件」を先に決めておく

4つ目の概念は「幻覚ループの検出」です。

AIが「正しいと思い込んだまま、間違い続ける」状態を、原文では「幻覚ループ」と呼んでいます。AIは、自分の間違いに気づけないことがあるんですよね。間違いの上に間違いを重ねながら、どんどん正確さから離れていく。これを止めるための「停止条件」を、先に設計しておく必要がある、という話です。

経営の言葉に翻訳すると、「エスカレーション基準の事前設計」に近いです。

「どの条件になったら人間の判断を仰ぐか」を先に決めておく。「ここまでは任せる、ここからは自分が見る」という境界線を、感覚じゃなくて、明文化した条件として持っておく。

組織運営でも同じですよね。「売上がこのラインを下回ったら社長に報告」「クレームがこの件数を超えたら対応フローを変える」みたいな基準は、多くの経営者の方が持っていると思います。AIを使う場合も、まったく同じ発想で「停止条件」を設計しておく必要があるんです。

ここで大事なのは「先に決めておく」という点です。

渦中で判断すると、感情や状況に引っ張られるんですよね。だから私は、うまくいっている間に「うまくいかなくなったらどうするか」を決めておくようにしています。

これはAIに限った話じゃなくて、経営判断全般に効く原則だと思っています。冷静なうちに限界値を決めておく。これができている経営者は、いざという時に崩れないんですよね。

20代の頃、ECサイトを立ち上げて急拡大させた翌年に、取引先の詐欺に遭って資金繰りが一気に破綻したことがあります。倒産はギリギリ回避しましたが、連帯保証で背負うものも背負いました。あの時「どこまで攻めて、どこで守るか」の基準を持っていなかった。

停止条件を先に決めることの大切さは、あの経験があるから人一倍わかるのかもしれません。今の「在庫を持たない・レバレッジが効く仕組みにこだわる」という事業スタイルも、あの経験からの学びです。

概念⑤ AIに渡す前に「データを洗う」

5つ目の概念は「観察のクリーニング層」です。

AIに仕事をさせるとき、インプットになるデータや情報の質が悪いと、どれだけ優れたAIでも出力は悪くなります。「質の低い材料からは、質の低い結果しか出ない」。これはAIの世界では、基本中の基本なんですよね。

「観察のクリーニング層」というのは、AIに渡す前に、データや情報を整理・浄化するステップを仕組みの中に組み込むことです。ノイズの多いデータを薄めて、AIが判断しやすい形に整えてから渡す層、ですね。

これは、私のAIチームが実際に構築してくれている仕組みから学んだことでもあります。

経営判断に使っているKPIのデータが、外部APIの不具合で古いまま止まってしまったことがあったんです。ただ、うちの仕組みは「このデータは古い」と検知したら、その数字を使った経営判断そのものを自動でストップするようになっている。だから気づかずに古い数字で判断してしまう、という事故は実際には起きていません。

判断の土台になっている数字が、実態とズレたまま使われたら危ない。だから「ズレていたら判断ごと止める」という仕組みを先に作っておく。この「観察のクリーニング層」を仕組みとして持っておく重要さを、身近な例で実感した出来事でした。

データを集める仕組みと、データを使う仕組みのあいだに、「このデータは正しいか」を確認する層を必ず置く。これがないと、さっきの私みたいに、間違った前提のまま走り続けることになります。

経営の現場でも同じですよね。売上数字の定義が現場ごとにバラバラのまま集計している。顧客情報のフォーマットが統一されていない。そんな状態でAIに分析させても、出てきた答えは信用できないんです。

AIを使う前に「データの洗い場」を作る。地味に見えて、実は経営のアウトプットを左右する、すごく重要な設計だと思っています。

まとめ：社長の仕事が「手を動かす人」から「ループを設計する人」へ

Loop Engineeringの5つの概念を、経営の言葉に翻訳しながら見てきました。まとめると、こういうことです。

• Inner Loop vs Outer Loop → 実務はAIと仕組みに渡す。社長は全体のループを設計する監督者に徹する
• Harness is the Product → 毎回指示を考えるんじゃなくて、一定の品質を出す「治具」を作り込む。治具を磨くことが社長の仕事
• 検証者への集中 → 品質ゲートを設計して、基準を満たさないものは自動で差し戻す仕組みを作る
• 幻覚ループの検出 → AIに任せる前に「ここから先は人間の判断」という停止条件を先に決めておく
• 観察のクリーニング層 → AIに渡す前のデータを整理・洗浄する層を、仕組みに組み込む

この5つって、どれもAI時代の前から、経営に必要だった概念なんですよね。「仕組みを作る」「品質基準を設ける」「判断基準を先に決める」「情報の質を担保する」。ただ、AIが加わったことで、これらの重要性が一気に上がって、しかも「仕組みとして設計しやすくなった」時代が来た、ということだと思います。

私がこの考え方にこんなに共鳴したのは、「強みを尖らせて、弱みは仕組みに渡す」という、私自身の経営スタイルと重なるからなんです。

実行力が弱いなら、実行が自動で回る仕組みを作る。判断が遅れがちなら、判断基準を先に設計して自動化する。自分の限界を、仕組みで補う。これが私のやり方なんですよね。

Loop Engineeringは、その発想を、AIを使う時代の言語で体系化してくれた考え方だと感じています。

技術者じゃなくても、この5つの問いを経営に当てはめることはできます。

• 私はいま「実務担当者」と「設計者」の、どちらをやっているか
• 品質の基準を、先に決めているか
• データは「洗ってから」判断材料にしているか
• 「ここから先は自分が見る」という停止条件を、決めているか

ひとつだけ、立ち止まって、この問いに向き合ってみてください。きっと「あ、自分はここが弱いな」というループが、見えてくるはずです。

そして、その弱いループこそが、仕組みに渡せる場所なんですよね。

参考: Addy Osmani & Peter Steinberger「Loop Engineering」 https://addyosmani.com/blog/loop-engineering/

AI活用の実践的な話は、毎朝のYouTube LIVEでもお伝えしています。よかったら「私のループは、ここが弱いかも」という感想を、コメントで聞かせてください。