私たちは、AIエージェントを"社員"として企業に派遣するBPOプラットフォーム TechHive Agent を開発しています。この記事では、その中核にある 業務の構造化の方法論 — 賢いLLMに基幹業務を任せるために「業務側」をどう整えるか — を、設計判断とあわせて紹介します。実行基盤（Anthropic の Claude・セキュリティ）の話は別記事に分けました。

この記事の要点

LLMがいくら賢くなっても、非構造化・属人化した業務はそのまま任せられない

効くのは「モデルの賢さ」より「業務をAIが扱える形に構造化できているか」

そのための3点セット：ビジネスファンクションチャート(以下、BFC)（業務の座標系）／業務のSkill化／4段階リスクティア（AIと人の境界）

はじめに：LLMが賢くなっても、基幹業務はそのまま任せられない

Claude が「賢く」なるほど、こう考えたくなります — 「この賢さなら、人事や経理のような基幹業務も、そのまま任せられるのでは？」と。

ところが実際に業務へ投入しようとすると、たいてい最初の一歩で止まります。「で、どの業務を、どこまで任せていいんだっけ？」 — ここが決まらない。

理由ははっきりしていて、多くの基幹業務は 構造化されていない からです。手順も、判断基準も、例外対応も、担当者の頭の中にしかない（＝属人化）。構造化されていない業務は、どれだけモデルが賢くても「安全に任せられる単位」に切り出せません。

つまり、AIエージェントに基幹業務を任せるうえで本当に効くのは、モデルの賢さそのものより、業務を"AIが扱える形"に構造化できているか です。

以下では、私たちが HR 業務を対象に作った構造化の方法論を、3つの道具立てで説明します。

なぜ「モデル」ではなく「業務側」を設計するのか

私たちの設計思想はシンプルで、「エージェントを作らない」 です。推論・ツール実行・サンドボックスといった"エージェントの中身"は Claude に任せ、私たちが作るのは 業務をAIが安全に扱えるようにするインターフェース層 に集中します。

Amazon Aurora = PostgreSQL に、クラウド規模の運用と DX を被せたもの（中身は Postgres）
AWS           = 物理インフラに、抽象化と DX を被せたもの（中身はサーバー / ネットワーク）
TechHive      = Claude に「業務構造・権限・HITL」を被せたもの（中身は Claude）

成熟したプラットフォームの多くは、強力なコモディティ（Postgres、サーバー、そして今は LLM）の上に「運用・権限・DX」の層を被せることで価値を出しています。私たちの立場も同じで、エンジニアリングの主戦場は「天才モデルにプロンプトを盛ること」ではなく、乱雑な人手の業務を、型付きでテスト可能な単位に変換すること になります。以降の3つは、その変換をやるための道具です。

BFC：HR業務を186ファンクションに分解する

業務を"任せられる単位"に切り出すには、まず全体を測るための 共通の座標系 が要ります。私たちはそれを BFC（Business Function Chart） と呼んでいます。

日本企業のHR業務を 8つの機能軸・186ファンクション に体系化
国際標準 APQC PCF v7.4 をベースに、日本固有のプロセス（36協定、年末調整の各種控除、マイナンバー管理など）を追加
ISO 30414 / SHRM BoCK とも整合

機能軸ごとの内訳はこうなっています。

機能軸	ファンクション数
採用	32
労務	44
勤怠	14
給与	20
評価・育成	24
人事企画	23
問合せ対応	9
従業員関係	20
合計	186

重要なのは設計原則で、1ファンクション = 1スキル になるところまで分解している点です。粒度を揃えると、以下の4つの"単位"が一致します。

切り出しの単位 — どこからどこまでを1つの業務として扱うか
テストの単位 — 期待する入出力をどこで固定するか
権限付与の単位 — どのファンクションにどのツール権限を与えるか
置換の単位 — 制度変更時にどこを差し替えるか

「業務をAIに任せる/任せない」の議論は、この粒度が揃っていないと必ず曖昧になります。BFC は、その曖昧さを消すための物差しです。

業務を Skill にする：暗黙知を型安全な単位へ

BFC で切り出した1ファンクションを、実際にAIが実行できる形にしたものが Skill です。ベテランの頭の中にある暗黙知を、次の4要素に構造化します。

skill: 採用 / 応募者スクリーニング
├── prompt      … 判断のさせ方（役割・手順・出力フォーマット）
├── policy      … やってよい / いけない の境界（リスクティア、PII の扱い）
├── tests       … 代表ケースの期待挙動（回帰を防ぐゴールデン）
└── knowledge   … 参照する業務ナレッジ（判断基準・テンプレ・過去事例）

ここでエンジニア視点のポイントは なぜ tests を Skill の一部として持つのか です。LLM は非決定的で、プロンプトやモデルを更新すると挙動が静かにずれます。業務ロジックを「プロンプトに書いた文章」だけで管理していると、この"静かなズレ"に気づけません。Skill に代表ケースの期待挙動を同梱しておくことで、更新のたびに業務としての回帰を検知できる — つまり 業務ロジックをソフトウェアと同じ土俵で管理する ための構造です。

私たちにとって、この Skill こそが最大の納品物です。モデルは借り物で日々賢くなりますが、「その会社の業務をどう回すか」という知識は Skill として自社に残ります。

MAP → BUILD → SCALE：可視化して、実装して、定着させる

Skill 化を現場で回すプロセスが、この3フェーズです。順序に意味があります。

フェーズ	やること	成果物
MAP	HR現場に入り、業務プロセス・判断基準・暗黙知を可視化する。必要ならRPO/BPOとして実務も担いながら、AI化すべき業務を見極める	業務マップ（何を任せ、何を人に残すか）
BUILD	定型化できる業務を Skill として実装。既存の HR SaaS や社内フローと接続し、必要な箇所に人の確認を挟む	稼働する Skill
SCALE	実行ログと現場フィードバックで Skill を継続改善。制度変更にも追従させる	自走運用

MAP を飛ばして BUILD から入ると、"構造化されていない業務をそのまま自動化する"ことになり、冒頭の「どこまで任せていいか分からない」に逆戻りします。だから 可視化が先、実装が後 です。

到達点は、担当者が変わっても業務品質が保たれる状態 — 言い換えると、私たちが撤退しても回り続ける仕組み を現場に残すことです。

4段階リスクティア：AIと人の境界を「設計」する

業務を構造化しても、それだけでは任せられません。各ファンクションに 「AIに任せてよい上限」 を定義する必要があります。私たちは全操作を、結果の"取り返しのつかなさ"で4段階に分類しています。

Tier	種別	既定の扱い	例
1	Read Only（読み取り）	自動実行	応募データ取込、スクリーニング、勤怠集計
2	Internal Write（内部書込）	自動実行（監査あり）	ATS更新、Sheets書込、月次レポート
3	External Action（外部操作）	人間の承認が必要	メール送信、スカウト、面接日程の提案
4	Irreversible（不可逆操作）	必ず人間が承認	合否通知、内定通知、退職辞令

原則は 「AIは下準備、最終判断は人」。Tier が上がるほど、人の承認を強制します。加えて、分類だけに頼らないためのガードレールを重ねています。

PII 自動検出：個人情報を検出したら、その操作のリスクレベルを自動で昇格させる
デュアルチャネル承認：承認は Web UI と Slack の両方から可能（承認のためだけに管理画面を開かせない）
放置防止エスカレーション：承認がタイムアウトしたら、通知・再割り当てで滞留を防ぐ

なお、本番で稼働している persona は現時点では 採用が第一弾 で、労務などは順次拡張中です。BFC はHR全体をカバーする設計ですが、"設計上できること"と"今動いていること"は分けて捉えてください。マイナンバーのような最も機微な領域は、そもそも Tier 3–4 として人間の承認側に置いています。

まとめ

賢いモデル ≠ 任せられる。非構造化・属人化した業務は、そのままではAIに渡せない
効くのは業務側の設計 — BFC で座標系を作り、業務を Skill 化し、リスクティアで境界を引く
Skill に tests を持たせることで、業務ロジックを非決定的なLLMの上でも回帰管理できる

次の記事では、こうして構造化した業務を どう安全に実行しているか（Anthropic の Claude を使った実行基盤・Permission Policy・テナント分離・監査）を書きます。

私たちはこの仕組みを実際に企業へ導入する βパートナー企業を募集 しています。HR業務の属人化・自動化に関心のある方は、TechHive Agent をのぞいてみてください。

執筆：佐々木龍也