・AIに何百個も指摘させて直しても、次はまた同じ提案が来る。原因は「なぜ採用し、なぜ捨てたか」をどこにも残していないこと
・判断とその理由をログとして溜め、AIに読み返させる。そうやって自分専用に育つ業務ソフトを「ループウェア」と定義する
・ただし溜める仕組みは、寝転びながら押せるくらい楽でなければ続かない。フロントエンドの工夫まで含めてループウェアになる

AIに何百個も指摘を出させて、直して、また出させて。それなのに、次に同じ作業をしたとき、AIはまた同じ的外れな提案をしてくる。

心当たりのある方は多いと思います。

原因は、AIの賢さではありませんでした。あなたが「なぜそれを採用して、なぜあれを捨てたか」を、どこにも残していないからです。

この気づきから、僕はここ数日でツールを10個近く作りました。そしてそれらを「ループウェア」と名付けました。

尾原和啓さんとのポッドキャスト収録で、この話をぶつけてみたところ、返ってきたのは「それ、Palantirが同じ結論に辿り着いてます」でした。

そこから、評価関数、FDE、FOBO、そして「空回りしろ」という話まで転がっていった対談を記事にします。

「ソフトウェアならぬ、ループウェア」

尾原：今日は池田さんの中でブレイクスルーがあったっていう話で。

いけとも：そうなんですよ。これはぜひ尾原さんに伝えたい、というか概念を伝えて議論したいんですけど。

一言で言うと、ループエンジニアリングに向けた特定の業務専用ツールを作って、そこを回し続けるのが熱いんじゃないかと。そういうソフトウェアのことを、勝手に「ループウェア」と名付けまして。

尾原：あー、なるほどね。ソフトウェアならぬ、ループウェア。

いけとも：そうです。これから広げていきたいと思っています。

どういうことかというと、例えば我々、本を書いてるじゃないですか。

尾原：磨き込みですよね。

いけとも：今ちょうど構成段階に入っていて、細かいフィードバックとか修正をバンバン回しているんですよ。

前の本では、Excelに数百個の指摘を書いて力尽きた

いけとも：これまで僕がどうしていたかというと、1個前の本では、Claudeに全文読ませて、Excelで「今のこの文章はこうだけど、こう直したらいいんじゃないの」を理由つきで何百個も出させていました。

誤字脱字もあれば、内容もあれば、言い回しもあれば、つなぎもある。全部チェックしてやっていたんですね。

尾原：はい、はい。

いけとも：これで文章は直るんですけど、Excelに「全部対応したか」まで書くのが面倒くさいんですよ。

結局、ビフォーアフターは残るけれど、何をどう採用したかという細かいログは残らない。

今回も尾原さんに見てもらったり、編集者からフィードバックがあったり、自分でもAIチェックをかけて何百とドラフトに出したわけなんですけど、これをちゃんと残す仕組みを作ろうかなと思って、作ったんですよ。

尾原：なるほど。

いけとも：一言ごとに、AIとか尾原さんとか編集者とか、いわゆる出どころをすべて入れて。「今この原稿だけど、この部分こう直したらいいんじゃないの」に対して、そのまま採用するか、修正して直すか、採用しないか。

アクションをすべて残していって、新しいバージョンを作っていく。まあ、一日で作った簡単なものなんですけど。

「なぜ直さなかったか」まで残すと、AIがもう一度読める

いけとも：これが何がミソかというと、全部の提案に対して「これはやった」「これは採用したけどこう直した」という細かいログが残るわけです。

最近アップデートして、やらなかった場合は、なぜやらなかったのかという理由も追加できるようにしました。

尾原：はい、はい。

いけとも：細かくログを残すことによって、1回の構成で何百個かの「俺がなぜやったか、やらなかったか」が残るじゃないですか。

それをAIにもう一回全部読ませて、ブラッシュアップするということを始めたんですね。

これがループなんですよ。

尾原：なるほど。それがループってことですね。

いけとも：しかもこれ、細かい業務になったほうがいいんですよ。構成するとか、細部の部分がやっぱりなかなか精度が上がらないわけなので。

ある作業の細部を細かくログに残して、なぜそうしたかが分かるようにしていく。マイクロツールというか、マイクロじゃなくてもいいんですけど、そうやるのが第一だなと、3日ぐらい前に思いつきまして。

「俺は天才か」と思って機能を作り、実際に全部チェックしてみて、機能した、という感じなんですけど。

尾原：いや、これねトレンドですよ。本当にトレンドです。

尾原「その裏で溜まっているのは、評価関数です」

尾原：一般的には、今言ったようなことが致命的になるから、どうにか仕組み化していきましょうという中で発達してきたのが、GitHubのGitの考え方であるわけです。

デシジョントレースという言い方をするんですけれども。

一個一個の意思決定って、「こう修正したほうがいいんじゃないか」という判断ですよね。でもその裏側には、「本当は文章はこういうふうであってほしいから、ここの部分はこうするんだよ」という、評価関数（Eval）が隠れてるじゃないですか。

いけとも：ああ、はい。

尾原：そうすると、一個一個のデシジョンについて「やったかやらないか」のログも蓄積されるんだけれども、もっとデカいのが、その裏側で「我々が作る本って、どういう本がいい本なんだよね」という評価関数自体が蓄積されていく。

この評価関数が精緻なものになると、まさにループに向かう。

ループを閉じていくことによって、一回こっちが「こういうものがいいんだ」と伝えれば、それが勝手に自己改善されていく流れになる。そこが今のトレンドだったりするので。

いけとも：まさに、その評価関数って、我々の脳内にあるわけです。全体の文脈を踏まえて、採用するかどうか、どう直すかをやっている。

でも、一つの本でも何十万文字とかあって、一セクションも一万文字とかある。全部直したビフォーアフターしかないと、細かいジャッジは分からないんですよ。

結局、細部が。

折りたたみスマホで、寝転びながら本を磨く

いけとも：これを細部まで分かろうとすると、既存のツールでは無理なんですよね。メモ帳で管理するとそんなに細かく書けないし、Excelは面倒くさい。

業務ツールとして、細かいデシジョンを残すときに、業務もちゃんと回る形で使いやすくなっていないと、使わないじゃないですか。これが激アツだなと思っていて。

僕が作ったのは、今この折りたたみのスマホでやってるんですけど、折りたたみ最適化なんですよ。

左右に折りたたむタイプなので、左側に元の文、右側に提案があって、下で採用するかどうかを、寝転びながら決められる。これが最高なんですよ。

尾原：あー、なるほどね。おもろ。あ、ほんとだ、すげえ。

いけとも：昨日もそのツールを作った後に、作りながらやってるわけなんですけど。何百と出しながら、ソファに座って、子供が遊びに来たりしながら「あ、これいいじゃん」「これ違うな」ってやっていったら、データが溜まっていくし、仕事も快適に進む。

これをバイブコーディングでAIに作らせたら、自分専用に、めちゃくちゃ簡単に作れるんですよね。

これが激アツかつ、みんなやったほうがいいかなと思っていて。それをループウェアと言おうかなと思ってます。

尾原：結局、実際にリアルで使えるものって、2つの構造がなきゃいけなくて。バックエンドとフロントエンド。

後ろ側のデータ構造やアルゴリズムがしっかり動くものになることも大事なんだけれども、我々が今いちばん心配しているのは、AIのほうがパッとかっこいいものを作っちゃうから、認知過負荷を起こしてしまうことであって。

「もうこれでいいや」にならず、いかに楽しみながらフィードバックを入れていくか。しかもそのフィードバックが、点のフィードバックではなく、線であり面である。

池田さんと話してて面白いのが、バックエンドの発想もあるけど、フロントエンドが「自分が楽しい」「自分が楽してインプットできる」という、そこの工夫ですよね。

いけとも：僕はもともと、最初のキャリアがビービットという会社でのユーザビリティコンサルティングだったんです。あれがめちゃくちゃ効いてまして。

どこを押したら使いやすいのかとか、本当に地味な話です。

たとえば文字サイズが変えられないと1画面で見えないから、行間と文字サイズだけをその画面で変えられる機能を追加すると、めちゃくちゃ快適になるとか。

ビフォーアフターを見るときも、ビフォーが一部だと分からないときがあるので、ちょっと拡大して前後を出せるようにするとか。

昔やっていたUIのテクニックなんですよね。これを組み合わせることで、AIも使いやすいし、データも溜まりやすいし、僕が快適というソフトになる。ここにキャリアが効いてくるとは思わなかったです。

尾原：今大事なのが、ユーザーにとってのリーダビリティと、AIから見たときのフィーダビリティなんですよね。

結局、認知過負荷が起きるのは、AIが圧倒的な量で変更をドンと変えてくれるから、自分で何が変化して何がインプットなのかを把握できる量を超えちゃってるんですよ。

同じ結論に辿り着いて爆速成長しているのが、Palantirです

尾原：ちなみにですね、それと同じ結論に辿り着いて、今、利益が爆速成長中の企業がPalantirなんですね。

いけとも：確かに、そうか。

尾原：Palantirではそれを、オペレーショナルオントロジーという言い方をしていて。

結局、AIに自律的な判断を任すという話になったとき、LLMって確率的にブレてしまうから、ブレがクリティカルなミスになると困る。もう一つが、さっき言った評価関数として「何を良しとするんですか」という話です。

個別の中でオペレーショナルなレベルで蓄積されていくけど、たとえば「顧客の離脱を防ごう」とすると、放っておくと値引きしちゃって、結果的に経営的に見たら利益が下がりますよね、みたいな話になる。

つまり、評価関数って場所によって矛盾してくるんですよ。

いけとも：はい、はい。

尾原：じゃあ、こういうシチュエーションのときはこの評価関数を優先しなければいけない、とか。これを超える評価関数で自律的に動くときには、どの部署のどのレイヤーの人に承認を取らなきゃいけない、みたいな話をやっていく。

Palantirのオペレーショナルオントロジーは三層構造で、

・セマンティックレイヤー：一つ一つの意味解釈がズレないようにする層
・キネティックレイヤー：その意味解釈に対して、具体的にどのアクションを許すのか、許さないのか
・ダイナミックレイヤー：キネティックで動いたものが自動最適化していくときの、評価関数の矛盾や階層構造を管理し、人間が何に対して介入していくのかを決める層

やっぱり、もう僕たち、自動化は当たり前。自動化すると今度はループを閉じて自己改善系が当たり前。

でも自己改善系がループとして当たり前になったら、一個一個のループがバッティングしたり、どのループをどれに再利用するのか、どこではやっちゃいけないのかを決めていく。

まさに「ループウェア大事」みたいな、そういう概念ですよね。

FDEの本質は「現場に潜り込むこと」ではない

いけとも：こういう取り組みをする中で、やっぱりFDE（Forward Deployed Engineer）という言葉が流行っていると思うんですけど。

日本企業のFDEって、現場に入って課題解決するところで終わっちゃうんですよね。

でも、さっきのサイクルでいうと、発見して解決した後に、横展開して事業化するのが重要なわけで。こうした「後」がないケースが多いなと。

今のところは高機能コンサルというか、優秀な人が現場に行って、現場のことを知って解決します、というところで終わっちゃっているかなと。

尾原：おっしゃる通りです。

日本人の良さって、手段が大好きだから、現場の中に潜り込んで、めちゃめちゃ現場を磨き込んだら、結果的にむちゃくちゃ戦闘力が上がって、結果的にすげーいいプロダクトになります、という結果論としての競争優位性なんですよ。

それはいいんだけど、AIで全体が可視化できるようになってるし、自律化できるようになってるんだったら、なんでコアプロセスを磨きに行くところに、もっと命を燃やさないのかなと。

だから、今から絶対、日本に「なんちゃってFDE」が増えて、「なんとなく現場に潜り込んで自動化します」というだけのFDEが量産されるから、ちゃんと全体構造を語らなきゃいけないなと。

ビジネスの本質っていうのは、今やってる事業のコアな価値に対して、新しい価値をいち早く発見できて、いち早く実装できて、いち早く横展開できるというところに骨太さがあるから。

営業の現場でお客様との接点の中で「ふと、これが受けるんだ」という仮説だったり。コールセンターやマーケティングで「このクリエイティブ、このコピーが今のお客様に刺さってるんだ」だったり。SNSの中のお客様の自然発話の中で「こちらが想定していないような、こんな深い価値を喜んでいただいてるんだ」だったり。

そういうところをいかに発見して、でも発見したものを横展開するためには、言語化しなきゃいけないんですよね。

さらに言うと、言語化したものが売れるものにならなきゃいけないから、「それってプロダクトの中に反映されてるんですか」「販促グッズの中に展開されてるんですか」「ランディングページの中に展開されてるんですか」という話になってくる。

発見 → 言語化 → 接点への埋め込み → コンバージョンへの寄与のフィードバック。この4ステップです。

いけとも：めちゃくちゃ面白い。

尾原：だから僕は、クライアントの日報ツールやマーケティングの分析ツールに、今の池田さんが言うような言語化のやつを入れていってるんです。

いちばん大事なことって、言語化と分析をAIが自動反映するんじゃなくて、営業やマーケの方々の日々の共通言語として切磋琢磨して、表現の美しさやハマり具合をブラッシュアップしていくことだから。

日報の中から見つかった仮説、実際に適用したセールストーク、その中でいちばん刺さった美しいワーディング。常に日報の中から、新しい共通言語と価値観を抽出していく。

同じように、毎日入れる日報画面の中から「誰をどういう言葉で褒めるんだっけ」というフィードバック画面として、その共通言語を入れていく、みたいなことをずーっとやってて。

人間は常に褒め続けないといけない生き物だし、常に忘れる生き物だから、思い直してなきゃいけなくて。この辺はリクルートで学んだことですけど、いかに念仏化するか、という。

空回りのコストが低い時代に、逡巡する意味はない

尾原：AI時代で全部できるようになっちゃって、今、FOBO（Fear of Better Option）という言い方がすごいされていて。

昔はSNSの中で「他に楽しそうなことをやってるから、ずっとネットにアクセスしとかないと怖い」というFOMO（Fear of Missing Out）が流行ったんですけど。

今はAIで、どんどん今の自分よりベターなオプションがあるから、「この今の自分に集中していいのか」という集中ができなくなって、ベターオプションばっかり見に行くという現象が、経営学の中では半年ぐらい前からすごい言われるようになっていて。

だから、クライアントとの壁打ちで重要になってくるのは、逆にクライアントの認知空間が広がっちゃって「あれもやらなきゃいけないのか」「これもやらなきゃいけないのか」と言い始めるので、「ちょっと待ってください」と。

「別にあなた、ビル・ゲイツやスティーブ・ジョブズになりたいわけじゃないですよね」と。

あなたは、目の前のお客様に100年間愛され続ければ、別にそれでいいということかもしれない。究極で言うと、あなたの代でもう、あなたの個人技として美しく終わって、次の代は次の代のやつが作ればいい。

だから、バイアスってある種、あなたの美しさを高めていく表現でもあるから。

いけとも：確かに、そこを決めてあげるというか。トリプルループ理論とかありましたよね。日々のアクションがあり、数週間ぐらいでやる次の目標が本当に合っているのか、目的が合っているのか。

でも目的ばっかり考えていると、アクションも進まないから。まずはとりあえず受験に受かろうと、受かってから考えたらいいよねということもありで。決めるのは、やっぱり人間ですよね。

それができないと、大量の選択肢があって、良さそうなことを言われ、そこに混乱して動けなくなっちゃう。

尾原：だから特に、さっきのループウェアじゃないですけれども、一回ループを閉じてしまえば、その方向性でAIが寝てる間に最適化してくれる時代なわけじゃないですか。

そうすると、「より良い行動があるんじゃないか」と言って2週目の逡巡をしてやってる人と、「いや、とにかく今晩はこのパターンでちょっと本を最適化してみようよ」と言ってダーッと作らせて、朝見てみたら「ああ、違った。このオプションじゃなかった。別のループで作ろう」と。

別のループ、別のループ、別のループと言って、ひたすら目の前にあるオプションを自律化させてAIに任せ続ける人と。どっちが進化するんですかというと、空回り力のほうが自動化時代はいいと思うんですよね。

いけとも：空回り。確かに、確かに。空回ってるし、たまに本当に回ったりしますからね。

尾原：そうそう。空回りリスクが低いので、まさに自動化時代なんだから、変に逡巡するよりは、もうバンバン空回りしようよっていうほうがいいんじゃないかなと思いますよね。

いけとも：しかも空回りコストが低いですね、AIの場合は。完全に同意です。

おまけ：最近の実務ハック

いけとも：全然関係ない各論で言うと、バイブコーディングだけで話したら、Cursorが最近めちゃくちゃいいです。

激速なのと、あとGitHubという管理ツールとの連携がすごい上がってて。ワンクリックで改善・修正まで行くのを、同時に何個も流せるんで。

最近はClaudeでバーッと作って、大枠ができたらCursorに移動して、っていうふうにしてるんですけど、めちゃくちゃ速いです。

尾原：同じだ、同じだ。しかもね、これバイブコーディングだけじゃないんですよ。

ビジネス側の部署管理とか、仕様書マネジメントとか、お客さんとのスキルのやりとりとか。結局、今やもうお客様とエージェントを共有しあって切磋琢磨するし、お客様もマーケティングの部署ごとに、それぞれ作ったエージェントやスキルを個別進化し合うので。

スキルとエージェントの部署管理にGitを使っていくときに、Cursorでやると、全体的な整合性を取ることだったり、一個のスキルをアップデートしたときに他の影響範囲を見て「こっちもアップデートしに行きましょうか」みたいな話とか、むちゃくちゃ楽で。

プログラミングやプログラミングの文書管理って、AIで生成してAIでシミュレーションしてAIで最適化できるので、GPUインフラの物量による最適化がもっともフィットする領域ですから。

エージェント・スキル管理・文書管理まわりの進化は、そこに乗っからないともったいないですよ。

まとめ：ループウェアは、あなたにしか作れない

尾原さんと話して確信が深まったのは、ここでした。

同じ機能のツールは誰でも作れる。でも、運用して選んできたログは、自分にしかない。

僕の好みも、あなたの現場の判断基準も、当然そこにしかありません。

だからループウェアは、多くの会社が自らの業務に適応させていく重要性が高まる領域です。既製品のツールでは難しいからこそ、自分の業務に適したものを作っていく。

やることは、それほど大げさではありません。

・日々の業務で、どの場面に、どんな選択肢があって、どちらを取ったか
・できれば、その理由も
・それを、なるべく面倒臭くない形で残す

あとはAIに回させればいい。サムネイル作成でも、スライド画像作成でも、構造は同じです。

そして忘れてはいけないのが、フロントエンドの工夫です。細かいログを残す設計にしても、面倒なら人間は使いません。寝転びながら押せるくらい、楽しくて楽なものにする。そこまで含めてループウェアです。

作りながら、この3日ほど、テンションが上がりっぱなしでした。

バイブコーディングで作り、ループエンジニアリングで回す。そうして生まれる、使うほど賢くなる自分専用のソフトウェア。それを僕はループウェアと呼ぶことにします。

まずは1個、あなたの一番面倒な業務から作ってみてください。空回りのコストは、もう十分に低いので。

よくある質問（FAQ）

Q1. ループウェアと、ループエンジニアリングは何が違うのですか？

ループエンジニアリングは「AIを自動で回す仕組みの設計論」、つまり方法論の名前です。対してループウェアは、その方法論で回すことによって人間の判断が蓄積され、使うほど賢くなっていくソフトウェアそのものを指します。「〜エンジニアリング」が方法論の名前で、「〜ウェア」が成果物の名前、という整理です。バイブコーディングで作り、ループエンジニアリングで回し、その結果がループウェアになります。

Q2. 何から作ればいいですか？大がかりなシステムが必要でしょうか？

必要ありません。むしろ、細かく限定された業務ほど向いています。今回の例も、本の原稿に対する修正提案を採用・修正・不採用で仕分けるだけの、一日で作った単機能ツールです。日々の業務のなかで「選択肢があって、どちらかを選んでいる」場面をひとつ選び、選んだ理由まで残せるようにするところから始めるのが現実的です。

Q3. 既製の業務ツールやメモアプリでは代用できませんか？

代用しにくいのは、細かい判断を残す作業そのものが面倒だと、人が続けないからです。メモアプリでは粒度が足りず、Excelでは記入の手間が勝ってしまいます。今回のツールでは、折りたたみスマホで左に原文・右に提案・下で採否を押せる形にしたことで、寝転んだまま何百件も処理できるようになりました。データが溜まる設計と、使っていて楽な設計は、セットで初めて機能します。

あわせて読みたい・聴きたい

新著（7/27発売）『Claude 最強のAI自動化術』：https://amzn.to/4eTUVG1

YouTube『いけともch』：https://www.youtube.com/@iketomoch

Podcast『いけとも尾原DeepなAIニュース』：https://open.spotify.com/show/3hGAbKZI5oo9PsbFI1IxTr

■合わせて読みたい

■関連記事