← 기사 목록
日本語https://zenn.dev/topics/ai/feed

コードでは書けない領域に降りる AI エージェント — ロングテール×暗黙知×暗黙考

원문 사이트로 이동 ↗

추출된 키워드

35개
ロングテール業務·5暗黙知·5暗黙考·5AI エージェント·5形式知·4RPA·4SaaS·4LLM エージェント·4Obsidian·4ロングテール DX·4Hermes Agent·4ミスミ·3決定論的·3テクニカルサポート AI·3Jitera·3Claude Code·3Cursor·3ChatGPT·3Claude.ai·3Applied Engineer·3FDE·3製造現場暗黙知 AI·3ダイキン工業·3状況応答的·3基幹システム·3SECI·3Nonaka·3Polanyi·3日経クロステック·3NEDO·2ERP·2Codex·2べき乗則·2Karpathy·2LLM Wiki·2

원문

11,480자
コードでは書けない領域に降りる AI エージェント — ロングテール×暗黙知×暗黙考

コードでは書けない領域に降りる AI エージェント — ロングテール×暗黙知×暗黙考

はじめに

自動化はずっと「形式知」止まりだった。RPA も SaaS も基幹システムも、フローチャート化できる業務しか飲み込めない。

AI エージェントは初めて、暗黙知と、その手前にある暗黙考（造語）という「臨機応変領域」に降りられる存在になった。日経クロステック 2026/4 が指摘する「ロングテール業務」と、Polanyi の暗黙知、Nonaka の SECI、そして個人レベルでの Obsidian × AI 分身運用 — これら全部が「同じ構造の問題」だったという話を整理する。

TL;DR

  • 形式知 → 暗黙知 → 暗黙考の 3 層モデル。下に降りるほど大量で、しかも今まで誰も扱えなかった。
  • ロングテール業務（担当者 1〜数名のニッチ業務）が長年自動化できなかったのは、ほぼ全部が暗黙知の塊だったから。
  • AI エージェントの本領は「コードでは書けない領域 = 状況に応じて臨機応変に動く領域」。決定論的な RPA や SaaS では届かなかった層に初めて降りる。
  • 個人レベルでは Obsidian に暗黙考をラフに溜める × AI エージェントが分身として使う運用が成立。企業レベルではロングテール DXの解像度が一気に上がる。

知の地層モデル

3 つを縦に並べると、知の地層になる。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ EXPLICIT ]    形式知
                マニュアル / SOP / コード化済
                ←─ 従来の自動化が扱えた領域
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ 水面（言語化のライン）
[ TACIT ]       暗黙知
                熟達者の判断・コツ・例外対応
                ←─ ロングテール業務がここに沈んでいた
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ 
[ SUBTACIT ]    暗黙考
                違和感 / 仮説 / 迷い / 関心の方向
                ←─ 個人の中にしかない思考の素材
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

歴史的に、自動化技術はこの地層を上から順に降りてきた:

  • 基幹システム / ERP（1990s〜）— 形式知の中でも最も明確な大量定型業務だけ
  • RPA（2010s〜）— 形式知だが手作業に残っていた領域に降りる
  • SaaS（2010s〜）— 業界横断の形式知をテンプレ化
  • LLM エージェント（2023〜）— ここで初めて水面下に降りる。暗黙知、そして暗黙考まで

ロングテール業務 = 暗黙知の塊

大企業の業務分布はべき乗則に従う。

  • ヘッド: 数百〜数千人が同じ業務（経費精算・受発注・人事申請）→ 基幹システム / RPA で対応済
  • テール: 担当者 1〜数名しか触らない多種多様な業務 → 長年放置

日経クロステックは 2026 年 4 月、このテールを「ロングテール業務」と名付けた [1]。具体例:

  • プロジェクト別予算承認（条件付き・独自承認ルート）
  • 稀な備品購入や特殊な出張の多段階承認
  • 部署独自の経費精算ルール
  • 研究開発費・補助金関連の複雑な精算
  • 部署独自の Excel 集計・レポート作成
  • 低頻度部品の発注・在庫調整、ニッチな法務チェック

共通点は 「フローが部署や案件によって毎回違う」「担当者の頭の中にしかルールがない」。RPA / SaaS / 基幹システムでは ROI が立たない。

なぜか？ 業務量の少なさではない。業務の中身がほぼ暗黙知だったこと、これが本当の壁。

現場担当者へのインタビューで

暗黙知を言語化する作業が求められる。抽出が不十分だと、AI が正しく動作しない・例外対応ができない。 — 日経クロステック

「暗黙考」という新しい層

もう一段下の層がある。**暗黙知になる「前」**の層を本記事では 暗黙考（造語）と呼ぶ。

内容
暗黙知 (tacit knowledge) 言語化されにくい経験・判断基準（熟達者の知）
暗黙考 (sub-tacit thoughts) まだ知識化されていない、思考の揺れ・違和感・仮説・迷い・判断の癖・関心の方向性・何度も繰り返し考えるテーマ

具体例:

  • 「なんとなくこの提案、引っかかる」── 違和感
  • 「こう繋がってる気がする」── 仮説
  • 「A と B、どっちにすべきか今は決められない」── 迷い
  • 「自分はいつも数字より文脈を優先しがちだ」── 判断の癖
  • 「最近やたら〇〇のことを考える」── 関心の方向性

暗黙知が「言える前の知」なら、暗黙考は「知になる前の考」。Polanyi の暗黙知より手前にあり、もっと脆く、もっと量が多い。誰もが日々大量に生んでいるが、これまで記録する場所も、使う相手もいなかった。

なぜ AI エージェントだけが暗黙領域に降りられるか

核心はシンプルで、コードは決定論的、エージェントは状況応答的だから。

コード = 決定論的

RPA も SaaS も従来のスクリプトも原理は同じ。「if A then X / if B then Y」を事前に書く。条件分岐の網にハマっている限り完璧に動くが、網からはみ出した瞬間に詰む。ロングテール業務は「網からはみ出すのが日常」なので、決定論的アプローチは構造的に向かない。

エージェント = 状況応答的

LLM ベースのエージェントは違う。毎回、状況を読み、判断し、動く。同じ業務でも入力が違えば違うルートを取る。例外が来たら無理に処理せず、追加情報を要求する。判断基準が言語化されていなくても、自然言語の文脈から推測して動ける。これが**「臨機応変」**と呼ばれる性質。

暗黙知と暗黙考は「言語処理」で扱える

暗黙知や暗黙考は、コードでは捉えられないが、自然言語のニュアンスとしては表現可能な層。LLM はまさにこの「言語の曖昧さをそのまま扱える」性質を持っている。「こういう時はだいたいこうしてる」「違和感があるんだよね」「たぶんこっちな気がする」── こうした不完全な記述から、エージェントは 状況に応じた応答を組み立てられる。

現役エージェントの地図 — 「現在形」の市場

抽象論で終わらせないために、2026 年 5 月時点で実機が動いている例を並べる。個人 / 業務 × 暗黙知 / 暗黙考 の 2 軸で見ると、4 象限すべてに現役エージェントが存在する。

暗黙知 暗黙考
業務 ダイキン 製造現場暗黙知 AI（NEDO 最高賞 + AI 賞）/ ミスミ テクニカルサポート AI（正答率 9 割） Jitera（"tribal knowledge → living context" / "tacit knowledge that lives between the lines"）
個人 Claude Code / Codex / Cursor（コードベースへの直感判断） Hermes Agent（Obsidian 暗黙考を読む分身）/ ChatGPT / Claude.ai（揺れの対話表出）

業務 × 暗黙知 — ダイキン / ミスミ

  • ミスミ「テクニカルサポート AI」: 十数年のベテランエンジニアの判断を完全再現。お客様の図面・要件に対する技術判断で正答率 約 9 割を達成。「人にしか聞けなかった」業務がエージェントに置換できることを実証。
  • ダイキン工業「製造現場暗黙知 AI」: 工場の熟練工が持つ品質判断・調整ノウハウを AI 化。2026 年 NEDO プロジェクト最高賞 + AI エージェント賞を受賞。

業務 × 暗黙考 — 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 thatrarely get written down

これはまさに本記事でいう暗黙考の領域を、業務側の AI エージェント基盤として正面から狙っているメッセージ。

個人 × 暗黙知 — Claude Code / Cursor

個人エンジニアのコードベース全体への直感的判断を肩代わりする。「このリポジトリならこう書く」という属人的判断 = 暗黙知に AI が降りた状態。

個人 × 暗黙考 — Hermes Agent / ChatGPT・Claude

Hermes Agent（OSS）は Obsidian Vault に溜めた暗黙考そのものを読み込む分身として動作する。詳細は別記事 Hermes Agent — 第二の脳の実行エンジン を参照。

個人運用 — Obsidian × AI 分身

「整理しない」ことの価値

暗黙考は整理した瞬間に死ぬ。タグを付ける、フォーマットを揃える、見出しを切る ── これらの作業は、思考が固まる前の素材を切り捨てる。だから 

daily/
配下はラフのまま放置するのが正解。違和感も矛盾も中途半端な仮説も、そのまま残す。

2 層運用：daily / knowledge

  • （実体層）= 暗黙考のダンプ場。
    daily/<YYYY>/<YYYYMMDD>/
    AI は触らない（提案のみ、書き換えない）
  • （ハブ層）= INDEX + テーマ別 MOC。
    knowledge/
    AI が育てる。daily/ の暗黙考を読んで、関連クラスタを提案・追記

Karpathy 式 LLM Wiki の構造そのもの [2]。

人間 = 暗黙考を生む装置、AI = 暗黙考を整理して使う装置という分業が成り立つ。

常駐エージェント（Hermes）の役割

常駐型エージェント（Hermes 等）が日次で Vault を読み、暗黙考の中から「いま使えるもの」を取り出して再構成する。スマホから「あの件まとめて」と投げると、Hermes が Vault の暗黙考を読んで答える。暗黙考が初めて「呼び出して使えるもの」になった瞬間。

ロングテール DX への応用

同じモデルは企業の DX 文脈にもそのまま降りる。

段階内容
短期 LLM を使った暗黙知のインタビュー支援。担当者と AI が対話しながら判断基準を言語化（SECI の表出化を加速）
中期 担当者の「迷い」「違和感」「仮説」 = 暗黙考も収集対象に。Obsidian 的な場に「担当者の暗黙考プール」を作り、AI が活用
長期 暗黙知・暗黙考が AI 側に蓄積されてくると、担当者が直接やらなくても AI が代行できる業務が増える。状況に応じて毎回判断するため、ロングテールの「毎回少しずつ違う」性質に耐えられる

Applied Engineer / FDE の役割

現場の暗黙知 → 暗黙考まで降りて言語化を引き出すのは、上流コンサルでも純粋なエンジニアでもできない。「3 層を一気通貫で繋ぐ人」が、ロングテール × AI 時代の DX の主役。

別記事 「AI で消える職種」より「職種の中の業務」を見ろ でも触れている。

まとめ — 臨機応変こそ AI の本領

自動化技術は 形式知 → 暗黙知 → 暗黙考 の順に地層を降りてきた。決定論的コード（RPA / SaaS）はヘッドの形式知でぶつかった天井を越えられない。LLM エージェントだけが状況応答的に動けるから、暗黙知と暗黙考に降りられる。

  • 人間 = 暗黙考を生む装置（整理せず、ラフに大量に出す）
  • AI = 暗黙考を読んで使う装置（状況に応じて毎回再構成する）
  • この分業がロングテールを解き、個人の分身を育てる

「コードで自動化する」時代から、「コードでは書けないものを AI に任せる」時代へ。これは効率化の延長ではなく、自動化が扱える対象そのものが質的に変わったこと。

関連記事