コードでは書けない領域に降りる AI エージェント ── ロングテール × 暗黙知 × 暗黙考
自動化はずっと「形式知」止まりだった。RPA も SaaS も基幹システムも、フローチャート化できる業務しか飲み込めない。AI エージェントは初めて、暗黙知と、その手前の暗黙考という「臨機応変領域」に降りられる存在になった。
日経クロステック 2026/4「ロングテール業務 × AI」が指す現場の実感と、Polanyi の暗黙知、Nonaka の SECI、Karpathy 式 LLM Wiki、そして暗黙考（造語）を一本の地層モデルで繋ぐ。
自動化の主戦場は「形式知」から「臨機応変」へ移った。LLM エージェントだけが 暗黙知と暗黙考に降りられる ── だからロングテール業務が初めて解け、個人の思考の素材まで扱える時代になった。
5/17 の Vault メモ「ロングテール業務 × AIエージェント」と、5/18 の「Obsidian × Hermes — 暗黙考を扱う自分の分身」を組み合わせた記事。担当者数名の業務と個人の頭の中は、構造的には同じ問題（暗黙の層が大きすぎる）を抱えていて、両方とも AI エージェントで初めて扱えるようになる、というのが核心。
- 形式知 → 暗黙知 → 暗黙考の 3 層モデル。下に降りるほど大量で、しかも今まで誰も扱えなかった。
- ロングテール業務（担当者 1〜数名のニッチ業務）が長年自動化できなかったのは、ほぼ全部が 暗黙知の塊だったから。
- AI エージェントの本領は「コードでは書けない領域 = 状況に応じて臨機応変に動く領域」。決定論的な RPA や SaaS では届かなかった層に初めて降りる。
- 個人レベルでは Obsidian に暗黙考をラフに溜める × AI エージェントが分身として使う運用が成立する。企業レベルでは ロングテール DXの解像度が一気に上がる。
ロングテール業務 ── 担当者数名の地層
大企業の業務分布はべき乗則に従う。ヘッド側（数百〜数千人が同じ業務をやる、たとえば経費精算・受発注・人事申請）は基幹システムや RPA で長らくカバーされてきた。ところがその裾には、担当者 1〜数名しか触らない多種多様な業務が大量にある。日経クロステックは 2026 年 4 月、これを「ロングテール業務」と名付けた。
記事が挙げる具体例：
- プロジェクト別予算承認（条件付き・独自承認ルート）
- 稀な備品購入や特殊な出張の多段階承認
- 部署独自の経費精算ルール
- 研究開発費・補助金関連の複雑な精算
- ニッチな取引先オンボーディング
- 部署独自の Excel 集計・レポート作成
- 低頻度部品の発注・在庫調整、ニッチな法務チェック
共通点は明確で、「数百人規模の業務ではない」「フローが部署や案件によって毎回違う」「担当者の頭の中にしかルールがない」。だから RPA / SaaS / 基幹システムでは ROI が立たない。
ロングテール業務 = 担当者数名 × 多種多様 × 属人化の業務群。「重要だが個別最適化できない」ためにシステム化から取りこぼされてきた、企業内の最後の自動化フロンティア。
そこにある「暗黙知」の壁
ロングテール業務がこれまで自動化できなかった一番の理由は、業務量の少なさではない。業務の中身がほぼ暗黙知だったこと、これが本当の壁。
>2-1Polanyi の暗黙知
哲学者 Michael Polanyi（1958）の有名な命題に「We know more than we can tell」がある。言語化できる範囲を超えて、人は知っているということ。自転車に乗る、顔を見分ける、熟達した職人が「なんとなくこの曲がり具合がおかしい」と気づく ── これらは全部、本人が手順を全部は説明できない知識。これを暗黙知（tacit knowledge）と呼ぶ。
>2-2Nonaka の SECI と「表出化」
野中郁次郎のSECI モデル（1995）は、組織の知識創造を「共同化（Socialization）→ 表出化（Externalization）→ 連結化（Combination）→ 内面化（Internalization）」のループとして整理する。このうち最も難しいのが 表出化（Externalization）── 個人の暗黙知を言葉や図にして他者と共有可能にする工程。ロングテール業務の自動化が詰む最大の理由がここ。
>2-3ロングテール = 暗黙知の塊
担当者が少ないほど、業務は属人化する。属人化するほど、判断基準・例外対応・「これは前回こうしたから今回もこう」というローカルルールが暗黙知として個人の中に堆積していく。日経テック記事もまさにここを最大の壁として指摘している：
現場担当者へのインタビューで暗黙知を言語化する作業が求められる。抽出が不十分だと、AI が正しく動作しない・例外対応ができない。
言い換えると、ロングテール業務という地層は、暗黙知の海に沈んでいる。コードに落とすには、まず暗黙知を引き上げる必要がある。
その手前にある「暗黙考」
もう一段下の層がある。暗黙知になる「前」の層。本記事ではこれを暗黙考（造語）と呼ぶ。
>3-1定義
- 暗黙知 = 言語化されにくい経験・判断基準（熟達者の知）
- 暗黙考 = まだ知識化されていない、思考の揺れ・違和感・仮説・迷い・判断の癖・関心の方向性・何度も繰り返し考えるテーマ
暗黙知は「熟達者の中で固まった、説明しづらいけど確かに使われている判断」。暗黙考は「固まる前の素材」。SECI モデルでいうと、暗黙知の手前にある「個人の中でまだ循環している思考」の層。
>3-2具体例
- 「なんとなくこの提案、引っかかる」── 違和感
- 「こう繋がってる気がする」── 仮説
- 「A と B、どっちにすべきか今は決められない」── 迷い
- 「自分はいつも数字より文脈を優先しがちだ」── 判断の癖
- 「最近やたら〇〇のことを考える」── 関心の方向性
暗黙知が 「言える前の知」なら、暗黙考は 「知になる前の考」。Polanyi の暗黙知より手前にあり、もっと脆く、もっと量が多い。誰もが日々大量に生んでいるが、これまで記録する場所も、使う相手もいなかった。
知の地層モデル ── AI が降りていく順序
3 つを縦に並べると、知の地層モデルになる：
- 形式知（水面上）── マニュアル / SOP / 既にコード化された業務
- 暗黙知（水面下）── 熟達者の判断・コツ・例外対応・「言われてみればそうだ」
- 暗黙考（海底堆積物）── 違和感・仮説・迷い・癖・関心の方向
歴史的に、自動化技術はこの地層を上から順に降りてきた：
- 基幹システム / ERP（1990s〜）── 形式知の中でも最も明確な大量定型業務だけ
- RPA（2010s〜）── 形式知だが手作業に残っていた領域に降りる
- SaaS（2010s〜）── 業界横断の形式知をテンプレ化
- LLM エージェント（2023〜）── ここで初めて水面下に降りる。暗黙知、そして暗黙考まで
なぜ AI エージェントだけが暗黙領域に降りられるか
核心はシンプルで、コードは決定論的、エージェントは状況応答的だから。
>5-1コード = 決定論的
RPA も SaaS も従来のスクリプトも、原理は同じ。「if A then X」「if B then Y」を事前に書く。条件分岐の網にハマっている限り完璧に動くが、網からはみ出した瞬間に詰む。ロングテール業務は「網からはみ出すのが日常」なので、決定論的アプローチは構造的に向かない。
>5-2エージェント = 状況応答的
LLM ベースのエージェントは違う。毎回、状況を読み、判断し、動く。同じ業務でも入力が違えば違うルートを取る。例外が来たら無理に処理せず、追加情報を要求する。判断基準が言語化されていなくても、自然言語の文脈から推測して動ける。これが「臨機応変」と呼ばれる性質。
>5-3暗黙知と暗黙考は「言語処理」で扱える
暗黙知や暗黙考は、コードでは捉えられないが、自然言語のニュアンスとしては表現可能な層。LLM はまさにこの「言語の曖昧さをそのまま扱える」性質を持っている。「こういう時はだいたいこうしてる」「違和感があるんだよね」「たぶんこっちな気がする」── こうした不完全な記述から、エージェントは 状況に応じた応答を組み立てられる。
自動化の主戦場は 「形式知を効率化する」から 「臨機応変を肩代わりする」に移った。コードでは書けない領域こそ AI エージェントの本領。
現役エージェントの地図 ── 「未来形」ではなく「現在形」
抽象論で終わらせないために、2026 年 5 月時点で実機が動いている例を並べる。個人 / 業務 × 暗黙知 / 暗黙考 の 2 軸で見ると、4 象限すべてに現役エージェントが存在する。
>6-1業務 × 暗黙知 ── ダイキン / ミスミ
- ミスミ「テクニカルサポート AI」: 十数年のベテランエンジニアの判断を完全再現。お客様の図面・要件に対する技術判断で正答率 約 9 割を達成。これまで「人にしか聞けなかった」業務がエージェントに置換できることを実証した。
- ダイキン工業「製造現場暗黙知 AI」: 工場の熟練工が持つ品質判断・調整ノウハウを AI 化。2026 年 NEDO プロジェクト最高賞 + AI エージェント賞を受賞。退職による暗黙知消失の防波堤として、すでに次世代業務改革の柱に位置付けられている。
この 2 つは「業務特化型 × 暗黙知の表出化」の代表格。日経テックが指摘する「インタビューで暗黙知を引き出す」工程そのものを、AI が業務側に張り付いて常時行う構造になっている。
>6-2個人 × 暗黙知 ── Claude Code / Cursor
- Claude Code / Codex: 個人エンジニアのコードベース全体への直感的判断を肩代わりする。「このリポジトリならこう書く」という属人的判断 = 暗黙知に AI が降りた状態。
- Cursor: エディタ内 AI として、書き手の文脈直感を逐次置換していく。コーディング作業における暗黙知の最も日常的な置換例。
>6-3個人 × 暗黙考 ── Hermes Agent / ChatGPT・Claude
- Hermes Agent（OSS）: Obsidian Vault に溜めた暗黙考そのものを読み込む分身として動作。詳細は「Hermes Agent — 第二の脳の実行エンジン」。本記事の §07 PRACTICE で扱う構成のリファレンス実装。
- ChatGPT / Claude.ai: 単発の対話を通じて、本人すら言語化できていない思考の揺れを引き出す場として機能する。「考え中の話を投げる相手」という用途は、暗黙考の表出化の最も普及した形。
>6-4業務 × 暗黙考 ── Jitera
- Jitera: 公式サイトで自身を「turns your code, docs, decisions, and tribal knowledge into living context」と位置付け、さらに「looking one step ahead — at the tacit knowledge that lives between the lines… including the things that rarely get written down」と明示。これはまさに本記事でいう暗黙考の領域を、業務側の AI エージェント基盤として正面から狙っているメッセージ。コード・ドキュメント・決定だけでなく、「書かれていない、企業の動き方を形作る細部」までを living context として AI に渡すことが Jitera の差別化軸になっている。
暗黙知 (Polanyi) を AI 化するダイキン・ミスミと比べ、Jitera は「まだ書かれていない、まだ形になっていない」フェーズに正面から踏み込んでいる点で、業務側の暗黙考象限の代表例として位置づけられる。
2023 年時点ではどの象限も「未来の話」だった。2026 年 5 月、すべての象限に商業 or OSS の実例が出揃った。暗黙領域は議論や仮説の対象ではなく、実装競争の最前線に変わっている。
個人運用 ── Obsidian × AI 分身で暗黙考を扱う
個人レベルでは、Obsidian に暗黙考をラフに溜める × AI エージェントが分身として使う運用パターンが成立する。Hermes Agent 記事で扱った構成の思想的な土台がここ。
>7-1「整理しない」ことの価値
暗黙考は整理した瞬間に死ぬ。タグを付ける、フォーマットを揃える、見出しを切る ── これらの作業は、思考が固まる前の素材を切り捨てる。だから daily/ 配下はラフのまま放置するのが正解。違和感も矛盾も中途半端な仮説も、そのまま残す。完成度を求めると、入力意欲そのものが消える。
>7-22 層運用：daily / knowledge
daily/<YYYY>/<YYYYMMDD>/（実体層）= 暗黙考のダンプ場。AI は触らない（提案のみ、書き換えない）。knowledge/（ハブ層）= INDEX + テーマ別 MOC。AI が育てる。daily/ の暗黙考を読んで、関連クラスタを提案・追記。
Karpathy 式 LLM Wiki の構造そのもの。人間 = 暗黙考を生む装置、AI = 暗黙考を整理して使う装置という分業が成り立つ。
>7-3常駐エージェント（Hermes）の役割
常駐型エージェント（Hermes など）が日次で Vault を読み、暗黙考の中から「いま使えるもの」を取り出して再構成する。スマホから「あの件まとめて」と投げると、Hermes が Vault の暗黙考を読んで答える。暗黙考が初めて「呼び出して使えるもの」になった瞬間。
この分業が成り立つと、AI は単発のチャット相手ではなく、自分の文脈を持った継続的なパートナーに変わる。暗黙考を読める AI は、本人にしか語れない判断・癖・関心を理解した上で動ける。これが「自分の分身」と呼ぶに値する状態。
ロングテール DX への応用 ── インタビュー支援から暗黙考収集へ
同じモデルは企業の DX 文脈にもそのまま降りる。日経テック記事が示す「暗黙知のインタビュー支援」は、暗黙考レイヤまで降りるとさらに強くなる。
>8-1従来の DX: ヘッドだけを刈り取る
RPA / SaaS / 基幹システム導入はヘッド側の数百人業務を刈り取って終わっていた。テール側は ROI が立たないから放置。結果、現場の体感としては「導入したのに楽にならない」が残り続けた。
>8-2暗黙知の引き上げ（短期）
第一段階は、LLM を使った暗黙知のインタビュー支援。担当者と AI が対話しながら、判断基準・例外対応・コツを言語化していく。日経テック記事が「最大の壁」と書いた表出化工程を、AI が肩代わりする。SECI モデルでいう 表出化（Externalization）の高速化。
>8-3暗黙考の収集（中期）
もう一段降りると、担当者の「迷い」「違和感」「仮説」──つまり暗黙考も収集対象になる。これまでは「業務の知見」として記録する場所がなかったが、エージェント時代には「担当者の暗黙考プール」を Obsidian 的な場所に溜め、AI が活用する形が成立する。例外対応の質も、引き継ぎの質も、ここでようやく上がる。
>8-4常駐エージェントによる代行（長期）
暗黙知・暗黙考が AI 側に蓄積されてくると、担当者が直接やらなくても AI が代行できる業務が増えていく。RPA とは違い、状況に応じて毎回判断するため、ロングテールの「毎回少しずつ違う」性質に耐えられる。決定論的コードの 10 年分を、ここで一気に追い越す可能性がある。
別記事で書いた Applied Engineer / FDE の存在価値は、まさにここに直結する。現場の暗黙知 → 暗黙考まで降りて言語化を引き出すのは、上流コンサルでも純粋なエンジニアでもできない。「3 層を一気通貫で繋ぐ人」が、ロングテール × AI 時代の DX の主役。
コードでは書けないものこそ、AI エージェントの主戦場
自動化技術は 形式知 → 暗黙知 → 暗黙考 の順に地層を降りてきた。決定論的コード（RPA / SaaS）はヘッドの形式知でぶつかった天井を越えられない。LLM エージェントだけが状況応答的に動けるから、暗黙知と暗黙考に降りられる。
個人レベルでは Obsidian に暗黙考を溜め、AI 分身が読んで使う運用が成立する。企業レベルでは ロングテール業務がついに自動化対象になる。同じ構造の問題が、個人と企業の両方で同時に解かれ始めている。
- 人間 = 暗黙考を生む装置（整理せず、ラフに大量に出す）
- AI = 暗黙考を読んで使う装置（状況に応じて毎回再構成する）
- この分業がロングテールを解き、個人の分身を育てる
「コードで自動化する」時代から、「コードでは書けないものを AI に任せる」時代へ。これは効率化の延長ではなく、自動化が扱える対象そのものが質的に変わったこと。ロングテール業務が解けるのも、個人の分身が成立するのも、根は同じ。