私たちは、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 をのぞいてみてください。
執筆：佐々木 龍也