【幕間】自律運用に、通信の知識は要らない ― 私はそれを、自分の身体で 16kg 分検証した

Telco × Agentic AI ／ 幕間（第 17.5 回）― Act 1 と Act 2 のあいだで
2026 年 8 月 ／ 著：ヒキノ ヒロユキ

🎧 音声で聴きたい方はこちら
本文を読む前に、音声で全体像をつかみたい方はこちらからどうぞ。
再生ボタンを押すだけで聴けます

この回について ― 通信の知識は、一切要りません

前回（第 17 回）で、Act 1 が閉じた。第 1 回から数えて 17 回、番外編を含めて約 7 万字。ここから Act 2 に入る。

……のだが、その前に一度、息継ぎをさせてほしい。

本稿は連載の本筋ではない。幕間（Intermission） である。

そして、これが本稿でいちばん先に書いておきたいことなのだが ―

この回には、通信業界の知識が一切要らない。むしろ、通信と無縁の方に読んでいただきたい。

私はこの連載を「Telco × Agentic AI」と題して、基地局やコア網の話を書いてきた。しかし、書き進めるうちにどうしても伝えたくなったことがある。

製造業の生産管理でも、医療の現場オペレーションでも、物流・流通でも、小売でも、バックオフィスでも、同じ形の仕組みが成立する。通信は、たまたまその問題が早く、濃く現れた領域にすぎない。

だから本稿では、専門用語を使わない。使うときは、その場で言い換える。題材にするのは、ネットワークではなく 私の身体 である。

私はこの 4 か月、連載で書いてきたのとまったく同じ構造を、自分の身体で回していた。

まず、事実から

数字だけ先に置く。

4 月 1 日に Microsoft に入社した。その 5 日後から、これを始めていた。連載を書きながら、裏でずっとこれが走っていた。

そして — ここが本稿を書く理由なのだが — 特別なことは何もしていない。
ジム通いも、トレーナーも、特殊な食材も、サプリメントも使っていない。運動と呼べるのは、1 日 1 万歩ほど歩くことだけである。

毎日欠かさずやったのは、2 つだけだ。

1. 毎食、写真を撮る

2. 毎朝、体重を測る

これだけだ。あとは、その 2 つが生むデータの上で、AI と一緒にループを回していた。そして — これが本題なのだが — 回しているうちに、ループのほうが勝手に賢くなっていった。

これはダイエット記事ではない

正直に書くと、私はこの体験を「ダイエットの成功談」として書く気がまったくない。世の中にその手の記事は無数にあるし、私が付け足せることは何もない。

私が書きたいのは、こちらだ。

この 4 か月間に自分の身体で起きたことは、本連載 Act 1 で 7 万字かけて書いてきた構造と、一字一句同じだった。

• 「分かっているのに、できない」という空白があった

• 続けられない観測は、無いのと同じだった

• 判断は、放っておいたら勝手に 3 層に分かれた

• 繰り返した判断は、やがてルールとして固まった

• 効かせすぎて、一度は身体のほうが壊れかけた

• そして、正解そのものが途中で動いていった

この 6 つは、連載で言えば順に「実行層の空白」「観測の壁」「Tier 構造」「ルール結晶化」「統制の設計」「ドリフト」にあたる。ただ、それらの用語は覚えなくていい。 中身は上の 6 行で全部だからだ。

つまり本稿は、ダイエット記事の形をした、理論の自己適用レポートである。順番に見ていく。

1. 「痩せたい」は判断であって、実行ではない ― 実行層という空白

第 3 回で、私はこう書いた。自律ネットワークがある段階で止まっている理由は、観測でも判断でもなく、実行層という構造的空白である、と。

少し言い換える。どんな運用も、この 3 つの層でできている。

• 観測：今どうなっているかを知る

• 判断：どうすべきかを決める

• 実行：実際に手を動かす

多くの現場では、前の 2 つはかなり進んでいる。ダッシュボードもあるし、AI もある。しかし最後の 1 つが埋まらない。だから自動化があるところで頭打ちになる。

ダイエットは、この空白の、おそらく人類で最も普及した実例である。

考えてみてほしい。「痩せたい」と思っている人が、何をすれば痩せるかを知らないということは、まずない。食べる量を減らし、消費を上回らないようにする。誰でも知っている。判断層は、とっくに解けている。

観測層も、実はそれほど難しくない。体重計に乗れば数字は出る。

にもかかわらず、痩せない。

意図と結果のあいだにある「実行」が埋まっていないからだ。

これは、私が 17 回かけて書いてきた業界の状況と、構造的にまったく同じである。何をすべきかは分かっている。監視ダッシュボードも整っている。それでも自動化が進まない。間が空いているからだ。

だから私は、ダイエットを「意志の問題」として扱うのをやめた。実行層を設計する問題として扱うことにした。

2. 観測層 ― 測定コストを、限りなくゼロに近づける

第 15 回（観測の壁）で、私は「観測できないものは制御できない」と書いた。そして観測の本当の壁は、精度ではなく 観測を続けられるかどうか にあるとも書いた。

ダイエットで、これは残酷なほどそのまま当てはまる。

カロリー計算が続かない理由は、計算が難しいからではない。毎食、記録するのが面倒だからである。1 食あたり 3 分かかる作業を 1 日 3 回、120 日続けろと言われて続く人は、ほとんどいない。観測コストが、観測の継続性を殺す。

私が使ったのは「あすけん」というアプリである。ここで効いたのは、栄養データベースの正確さではなく、画像を撮るだけで記録が終わるという一点だった。＊ちなみに、あるけんを紹介してくれたのはChatGPTだ。

• 食事の写真を撮る → AI が料理を推定し、カロリーと PFC（タンパク質・脂質・炭水化物）に分解する

• 目標体重を入れる → 1 日の摂取上限と PFC バランスが自動で決まる

• 毎朝、体重を測る → 時系列で積み上がる

観測の作業コストが、1 食あたり数秒まで落ちた。ここが最初の、そして最大の分岐点だったと思っている。

ネットワーク運用でも同じことが起きている。テレメトリを「取れるか」ではなく、取り続けても運用が破綻しないか。観測の設計とは、精度の設計であると同時に、コストの設計である。

そしてもう一点。私は 2 種類の観測を並行して見ていた。

体重だけを見ていると、判断が 3〜5 日遅れる。カロリーだけを見ていると、実際に効いているのか分からない。両方を並べて初めて、ループが閉じる。

これは、どの業界でも同じだろう。売上だけを見ていても手は打てないし、作業ログだけを見ていても効果は分からない。（連載ではこれを第 15 回で Outcome / Substrate と呼んだ。）

3. 判断層 ― 2 つの AI が、勝手に役割分担していた

ここが、本稿でいちばん書きたかった部分である。

私はこの 4 か月、2 種類の AI を使っていた。

あすけんの AI ＝ 定型判断（決定論的な処理）

写真からカロリーを推定し、目標との差分を出し、PFC の過不足を返す。毎日同じ形式で、同じ処理を、確実に返す。ここに創造性は要らないし、要らないことが価値である。＊ちなみに、あすけんじゃなくても同じような機能であれば、なんでもよいと思う。たまたま私はあすけんを使っただけです。

Claude ＝ 非定型判断（推論）

問題は、あすけんが答えてくれないことのほうにあった。実際に私が投げた問いは、たとえばこういうものである。

• 「ケトジェニックとローファット、自分にはどちらが向いているのか」

• 「ローファットにしたら、便通が完全に止まった。何が起きているのか」

• 「2 週間、体重がまったく動かない。設計が間違っているのか、それとも待つべきなのか」

• 「16 時間断食を併用していいか。自分の生活で成立するか」

こういう問いは、定型処理では捌けない。私はあすけんのグラフや記録のスクリーンショットをそのまま Claude に見せて、状況を読ませ、次の一手を相談していた。人間のコーチをつけていたのに近い。

さて、ここで連載の読者にはピンときてほしい。

これは、番外編（第 9.5 回）で書いた Tier 構造そのものである。

私は、これを設計してから始めたわけではない。やっているうちに、自然にこの形に落ちた。 それが、この構造がある種の自然さを持っていることの、ささやかな傍証になるのではないかと思っている。

4. 実行層 ― 頭と手のあいだ、最後の 30 センチ

第 4 回で私は「頭・手・統制」の 3 要素を挙げた。

ダイエットにおいて、頭は AI が完全に代替できる。何をどれだけ食べるべきかは、もう計算されている。
統制もほぼ自動化できる。上限を超えればアプリが警告する。

しかし、手だけは代替できない。

皿から口までの 30 センチ。ここを動かすのは、どうやっても私自身である。ダイエットにおける実行層は、構造的に人間に固定されている。

だから私が設計したのは、「手を強くすること」ではなかった。意志力を鍛えるアプローチは、私には向いていない。そうではなく、手が間違えにくい状況を先に作ることだった。

最後の 16 時間の話は、もともと自分のアイデアではなく、Claude と相談しながら取り入れたものである。重要なのは、「16 時間が一般に正しいか」ではなく、「自分の生活で破綻せずに回るか」 を確かめたことだった。

これは、エージェントに実行させるときの設計と、驚くほど似ている。実行主体を賢くするのではなく、実行環境の側で失敗の余地を削る。 サンドボックス、権限の最小化、ロールバック可能性 — 連載で繰り返し書いてきた話と、発想は同じである。

5. Learning Loop ― ルールが、結晶化していった

そして本稿の核心。

最初の 2 週間、私はほぼ毎日 Claude に相談していた。

何を食べるか、どう組み合わせるか、この数字はどう読むか。判断のたびに推論を呼んでいた。第 9.5 回の言葉を借りれば、Tier 1 の棚が空っぽの「新生児」状態である。推論への依存が最大で、そのぶん時間もかかっていた。

この 4 か月は、その棚が埋まっていく過程だった。順番に振り返る。

5-1. 探索フェーズ ― 世間の正解が、自分の環境で動くとは限らない

減量の王道は、大きく 2 つあるとされる。ローファット（脂質を抑える）とケトジェニック（糖質を抑え、脂質からエネルギーを取る）である。

私はまず、ケトジェニックから入った。理由は正直に書くと、YouTube でよく見かけたからである。米を抜き、脂質を積極的に取る食事に切り替えた。

結果、合わなかった。

そこでローファットに切り替えた。こちらは、私の身体では明らかに機能した。

これは、ネットワーク運用をやってきた人間には、ひどく馴染みのある話ではないだろうか。業界のベストプラクティスをそのまま持ってきても、自社網では動かない。 一般解は出発点にはなるが、答えではない。自分の環境で回して、初めて何が効くかが分かる。

ルールの棚は、他人から借りてきたものでは埋まらない。自分の環境で検証して初めて、棚に置ける。

5-2. 単一指標を最適化したら、見ていなかった場所が壊れた

ローファットに切り替えて、私はそれを徹底した。脂質をほぼゼロに近いところまで削った。体重は順調に落ちた。

そして、別のところが壊れた。

それまで私は、どちらかといえばお腹が緩いほうで、排便は 1 日に何度もあった。それが、完全に止まった。 ひどいときは 1 週間近く出ない。心配になるレベルだった。

ここで起きていたことは、はっきりしている。

私は「体重」という単一の KPI を最適化して、観測対象に入れていなかった指標を壊したのである。

第 15 回（観測の壁）で私は、観測対象の選び方こそが本当の壁だと書いた。まさにこれだった。体重だけを見ていれば、この期間の運用は「順調」と評価される。ダッシュボードは緑のままだ。しかし系としては、明らかに劣化していた。

対処として、私はあすけんに課金し、PFC の配分を「削る」のではなく「設計する」対象に変えた。Claude にも状況を説明し、脂質をどこまで戻すべきかを相談した。

出た結論は、「ローファットではあるが、ゼロファットではない」 という中間点である。極端は、どちら側も破綻する。

5-3. 停滞期 ― 「効いていない」と「まだ出ていない」は、観測では区別できない

最初のうちは、面白いように落ちた。

ところが途中で、約 2 週間、体重がまったく動かない期間が来た。食事は変えていない。カロリー収支も赤字のままだ。それでも、動かない。

このとき私が直面したのは、運用者ならよく知っているはずの問いである。

この 2 つは、観測データだけでは区別できない。そして区別できないまま不安になると、人は手を打ちすぎる。設計を変え、さらに削り、結果として系を壊す。

私を止めたのは、Claude だった。「そういう落ち方をするものだ」と説明されたことで、設計を変えずに待つという判断ができた。実際、2 週間の横ばいのあと、体重はまた落ち始めた。

ここで気づいたことがある。判断層の役割は、次の一手を出すことだけではない。「今は何もしないでいい」と言えることも、同じくらい重要な出力である。

自律運用の議論で、私たちはつい「何をするか」ばかりを設計する。しかし現場でループを壊すのは、たいてい焦って余計な手を打つことのほうだ。

5-4. 結晶化したルール

こうした試行錯誤を経て、私の中に残ったのが以下である。もう考えない。判断が要らない。

注目してほしいのは、ルール 4 である。「会社の社食は気にせず食べていい」という判断は、判断そのものを免除するルールだ。カロリー計算をしなくていい時間帯を作ることで、1 日に必要な意思決定の回数が減る。

これは、運用でいえば 「この範囲の変更は承認不要」と決めることに等しい。すべてを制御しようとすると、制御そのものが破綻する。どこを制御しないかを決めるのも、統制の設計である。

5-5. そして、聞かなくなった

棚が埋まると、どうなるか。

Claude に相談しなくなった。

最初の 2 週間は毎日だった。1 か月を過ぎたあたりから明らかに減り、いまは例外が起きたときにしか開かない。判断の大半は、推論を介さず、ほぼ一瞬で、確実に処理されている。

第 9.5 回で、私はこう書いた。

自分で書いておいて何だが、これを自分の身体で体験することになるとは思っていなかった。

コストの動き方も、書いた通りだった。

運用するほど、判断は軽く、速く、安くなった。
能力とコストが逆方向に動く。第 9.5 回で「少し直感に反する帰結」と書いたあの動きが、そのまま起きていた。

私が「再現性がある」と感じているのは、16.2kg という数字のことではない。この結晶化のプロセスのほうである。

6. Governance Loop ― 下限は、割ってから知った

第 14 回で「統制は制約ではなく、設計の起点である」と書いた。これも、身体でやると意味がよく分かる。ただし、正直に書いておかなければならないことがある。

私は、ガードレールを先に置けなかった。割ってから、その存在を知った。

暴走する方向は 2 つある。食べすぎる方向と、減らしすぎる方向である。そして危険なのは後者だ。減量という文脈では、「減らしすぎ」は指標の上ではむしろ成功に見えるからである。

私は一時期、摂取を 1 日 1,200kcal 前後まで落としていた。体重は落ちる。数字だけ見れば最適化は進んでいる。しかし、身体のほうが先に音を上げた。

そこで初めて、設計値を計算し直した。

1,200kcal は、維持から 1,000kcal 以上引いていたことになる。制御としては効いていたが、系としては壊れかけていた。

1,800kcal に戻したところ、体調は安定し、それでいて体重はきちんと落ち続けた。強く効かせるほど良い、ではない。 系が持続できる範囲でいちばん効く点を探すのが設計である。

自律的に走るループには、必ず「止める条件」を先に埋め込んでおく ― これは、エージェントに権限を渡すときの原則そのものだ。走らせる前に、止め方を決める。

そして私は、それを先にやらなかった。だから身体が壊れかけて、初めて学んだ。 ネットワークで同じことをやったら、学習の代償はもっと高くつく。

7. Drift ― 正解そのものが、動いていく

もう一点、運用してみて初めて分かったことがある。

維持カロリーは、固定値ではない。

90.8kg のときの維持カロリーと、74.6kg のときの維持カロリーは違う。体重が落ちれば、それを維持するのに必要なエネルギーも落ちる。つまり、同じ食事を続けているだけで、赤字は自動的に縮んでいく。

これが、多くの人が「同じことをしているのに止まった」と感じる理由の一つだろう。実際には、同じことをしていない。環境のほうが動いているのである。

第 9.5 回で挙げた 6 つの技術部品のうち、私が Drift Monitor と呼んだものが、まさにこれを担う。

ルールを結晶化させることと、結晶化したルールが陳腐化することは、同時に起きる。だから Learning Loop は「一度学べば終わり」ではなく、回り続けなければならない。

身体でやると、これが 4 か月で体感できる。ネットワークだと、気づくのに数年かかる。

まとめ ― Act 1 の全論点を、身体の言葉に置き換える

ここまでの話を、1 枚にまとめておく。左が Act 1 で 7 万字かけて論じた概念、右がこの 4 か月で自分の身体に起きたことである。

もし本稿から Act 1 に遡って読んでくださる方がいたら、この表を索引として使っていただければと思う。右側を先に理解してから左側を読むほうが、たぶん早い。

そして、この構造はあなたの現場にもある

本稿では身体を題材にした。しかし私が本当に言いたいのは、題材は何でもいいということである。

「実行層の空白」がどこにあるかを、いくつかの現場で探してみる。

並べると、同じ形が見える。観測は進んだ。判断も AI が担えるようになった。しかし「実際に手を動かす」ところだけが、いまだに人に固定されている。

そして、そこが埋まらないかぎり、どれだけ観測と判断を高度化しても、システムは自律的に回らない。人がボトルネックとして残り続ける。

私が連載で「実行層という空白」と呼んできたのは、これである。通信業界に固有の話ではまったくない。 通信は、規模と速度の要求が極端だったために、この問題が早く、濃く現れただけだ。

だから逆に言える。通信業界でこの空白を埋める設計が確立すれば、それは他の業界にそのまま持ち出せる。 私が Act 2 で業界横断のレイヤーに議論を引き上げようとしているのは、この見立てによる。

8. なぜ、これを技術連載に書いたのか

理由は 3 つある。

1 つめ。 私は Act 1 で「実演を伴う論説でありたい」と書いた。書いた構造が本当に機能するのかを、まず自分で試してみたかった。ネットワークで検証するには時間もラボも要るが、自分の身体なら、今日から回せる。いちばん近くにあった検証環境が、自分だった。

2 つめ。これが最大の理由だ。 私は、自律運用の仕組みが「通信業界の専門知識がないと分からないもの」と思われることを、何より避けたい。

クローズドループも、Learning Loop も、Governance Loop も、抽象的な図として描くと、どうしても他人事の絵に見える。用語を並べれば並べるほど、「これは自分の現場の話ではない」と思われてしまう。

しかし構造は本当にドメインを選ばない。ネットワークでも、工場でも、病院でも、倉庫でも、そして人間の身体でも、同じ形をしている。だから、専門用語が 1 つも要らない題材で、同じことが起きると証明したかった。

身体なら、誰でも持っている。実行層が埋まらない苦しさも、多くの人が知っている。これ以上に共通言語になる題材はないと思った。

3 つめ。 これは正直な話だが、17 回の連載を書き切ったところで、一度息を継ぎたかった。ここまでお付き合いいただいた読者の方に、少し肩の力を抜いた回をお届けしたい、という気持ちもある。

再現性について、ひとつ注意

数字だけが独り歩きすると危ないので、はっきり書いておく。

本稿は筆者個人の記録であり、医学的な助言ではない。そして私は、この 4 か月間、医師や管理栄養士の指導を受けていない。 アプリと生成 AI と自分の身体だけで回した、完全な自己流である。

実際、5-2 と 6 で書いた通り、私は二度、身体に異常を出している。それは設計の失敗であって、武勇伝ではない。専門家がついていれば、どちらも避けられた可能性が高い。

体重 90kg 台からのスタートだったからこの減量ペースが成立した面も大きく、開始時の体格・年齢・基礎疾患によって、安全な設計はまったく変わる。実践される場合は、必ず医師・管理栄養士に相談してほしい。

そのうえで、私が共有したいのは食事メニューでも減量ペースでもなく、「観測コストを落とし、判断を Tier で分け、ルールを結晶化させ、止める条件を先に置き、設計値のドリフトを監視する」というループの組み方のほうである。そこにだけは、ドメインを超えた再現性があると思っている。

次回から、Act 2 に入る

幕間はここまで。

次回から、Act 2 — 「Agentic AI Runtime そのものの方法論」を、業界横断のレイヤーで展開するシリーズ — が始まる。第 1 回は「パイプラインから多重ループへ」。本稿で身体を使って回してみせたループを、今度は正面から構造として解剖していく。
そして、ここだけは重ねて書いておきたい。

Act 2 は、通信業界の連載ではない。 題材として通信の例は使うが、議論の中身は、製造でも医療でも流通でもサービス業でも、そのまま成立するものにする。

もしあなたの現場にも、「分かっているのに、手が追いつかない」 という空白があるなら、この先の議論は、おそらくあなたの話でもある。
引き続き、お付き合いいただければ幸いである。

※ 本連載の用語「育つ自律ネットワーク（Self-Cultivating AN）」は筆者による造語です。ご引用の際は第 9.5 回をご参照ください。