Vibeコーディングが組織に入ると、「言い訳」が消える

組織に自律エージェントやVibeコーディングが入った現場を何度か見てきて、僕が一番おもしろいと思うのは、生産性が上がることそのものじゃない。会話から「言い訳」が消えることだ。「人が足りない」「忙しくて手が回らない」「うちは専門外だから」──こういう、できない理由の定型句が、いつの間にか出てこなくなる。代わりに「やろうと思えばできるよね、じゃあどうする」というポジティブな会話になる。これは検証済みの定理ではなく、いくつかの導入現場を見て腹落ちした僕の私見だ。この記事はその見立てを言葉にしておくためのものだ。

「できない理由」が、技術的な事実でなくなる

「言い訳」と書くと精神論みたいだが、僕が言いたいのはもっと構造的な話だ。これまで「人が足りない」「専門知識がない」は、たいてい本当の制約だった。新しい業務システムが欲しければエンジニアを採るか外注するしかなく、非エンジニアの現場リーダーが自分で作るのは現実的でなかった。だから「リソース不足」は言い訳ではなく事実で、そこで会話が止まるのは正しかった。

ところがVibeコーディングや自律エージェントが組織に入ると、その「事実だった制約」が崩れる。一例として、僕がある場で見たのは、コードを書いた経験がほぼゼロ──「関数って概念があるんだ」というところから始めた──新規事業畑のビジネス職の人が、自分で業務エージェントを組み上げてしまったケースだ（本人の自己申告で第三者検証はしていない一例として書く）。録音や議事録と、実際に作られた資料との「ズレ」を自動で検出し、検証ループに回す仕組みを自分で作り、昨日一日で複数件分の提案書を生成していた、という。数字の正確さはここでは重要じゃない。重要なのは、「専門外だからできない」が技術的な事実でなくなったという構造変化のほうだ。

制約が事実なら、それを指摘するのは言い訳じゃない。でも制約が崩れた後も同じ台詞を言い続けると、それは言い訳になる。Vibeコーディングが組織に入るというのは、この境界線を動かすことだと僕は思っている。

溜め込んだコンテキストが、ループ化した瞬間に資産に変わる

もう一つ、僕が強く感じている変化がある。それまで「ただのログ」だったものに、急に価値が出る現象だ。

議事録がわかりやすい。多くの組織で議事録は、書くのが面倒で、書いても読み返されず、フォルダの底に沈んでいく「コスト」だった。SNSのブックマークも、過去のやり取りのアーカイブも同じで、溜めるだけで使われない死蔵データだった。ところが、それらをエージェントが繰り返し参照するループの中に置いた瞬間、議事録は「決定や論点を引き出せる検索可能な文脈」に変わり、ブックマークは「自分の関心と判断の履歴」に変わる。溜めてきたコンテキストが、ループに載った瞬間に一気に引き出せる資産になる──議事録に急に価値が出た、と僕が言うのはこの意味だ。

これは僕の体感だけの話ではなく、AI開発の世界で言われている「コンテキストエンジニアリング」の考え方とも重なる。Andrej Karpathyはこれを、LLMをCPU、コンテキストウィンドウをRAMに見立てた「新種のOS」と表現し、要は賢いモデルを選ぶことより、その情報環境に何を載せるかで仕事の質が決まる、と整理している（出典: LangChain, “Context Engineering for Agents”）。組織に引きつけて言えば、議事録・アーカイブ・過去の判断は、エージェントというCPUに載せる「RAMの中身」だ。だからループを回し始めた組織では、データを溜めること自体の意味が変わる。捨てずに溜めてきた組織ほど、ループ化した瞬間に効く──というのが僕の見立てだ。

次に来る共通テーマは「ループエンジニアリング」だと思う

ここまでをまとめると、僕がいま組織のAI活用で次のフェーズの共通テーマだと考えているのは、一発のうまいプロンプトでも、賢いモデル選びでもなく、ループをどう設計するかだ。仮に「ループエンジニアリング」と呼んでおく。

さっきの非エンジニアの例も、効いていたのはAIに一回うまく質問したことではなく、「ズレを検出する→検証する→直す」という回り続ける仕組みを組んだことだった。別の現場では、チーム全員がSlackから使える組織展開型のエージェントを置いて、個人の便利ツールでなく組織の標準動作にしていた。共通しているのは、AIを「単発の道具」でなく「回り続ける環境」として組織に埋め込んでいる点だ。

なぜこれが「言い訳が消える」話と「コンテキストが資産になる」話に繋がるか。ループが回り始めると、(1)できない理由だった制約が技術的に崩れ、(2)溜めてきたコンテキストがそのループの燃料として効き始める。この二つが同時に起きるから、組織の会話のトーンが変わる。逆に言うと、ループを設計せずにAIを単発で使っているうちは、この変化は起きない。ツールを配っただけでは、言い訳は消えないし、議事録も死蔵のままだ。

念のため断っておくと、これは検証済みの結論ではなく、いくつかの導入現場を見た上での僕の仮説だ。反証もありうる──ループ化がうまくいかず、かえって「エージェントが当てにならない」が新しい言い訳になる組織もあるだろうし、ここで挙げた個別事例はいずれも本人の自己申告で、僕が第三者として裏を取ったものではない。それでも、「言い訳が消える」「コンテキストが資産になる」「次の鍵はループ設計」という三つは、別々の現場で繰り返し見えてきた手応えだ。

結論

組織にVibeコーディングが入って本当に変わるのは作業速度ではなく、「できない理由」が技術的に崩れて言い訳が消え、溜め込んだコンテキストがループに載った瞬間に資産へ変わることだ──そして次の共通テーマは賢いモデル選びでなくループ設計（ループエンジニアリング）になる、というのが、複数の導入現場を見て腹落ちした僕の私見である。

---

出典

• 「コンテキストエンジニアリング」の考え方・Andrej Karpathy のLLM=CPU／コンテキスト=RAM（新種のOS）比喩: LangChain, “Context Engineering for Agents”
• 本文中の個別事例（非エンジニアによる業務エージェント構築、組織展開型エージェント、生成件数など）は、いずれもある導入現場での当事者の自己申告に基づく一例であり、筆者が第三者として検証した数値ではない（外部検証を要する事実主張としてではなく、見立ての色付けとして記載）。