AI組織図の作り方：担当・引き継ぎ・承認の詰まりを見つける仕事の地図
AI組織図は、部署名やAIの人数を並べる図ではありません。一つの仕事がどこから始まり、誰が担当し、何を確認し、どこで人が判断し、次の担当へ何を渡すかを描く仕事の地図です。
この地図があると、「AIが動かない」という曖昧な問題を、担当がいない、完了条件がない、引き継ぎに根拠がない、承認依頼が判断できない、といった直せる問題へ分解できます。
まず、箱を描く前に一本の線を書きます。
仕事の開始
→ 担当が作る
→ 別の担当が検証する
→ 人が重要事項を判断する
→ 次の担当が実行する
→ 結果を確認して記録する
一つの担当が複数工程を受け持っても構いません。重要なのは役職の数ではなく、工程ごとの責任と受け渡しが切れていないことです。
最初に「一つの仕事」を両端まで決める
「マーケティングをAI化する」「営業部にAIを置く」では範囲が広すぎます。開始と完了を観測できる一つの仕事へ絞ります。
たとえば記事制作なら、次のように決めます。
- 開始：読者の問いと公開目的が決まった
- 完了：承認された版が公開され、実際のページを取り直して内容を確認した
「下書きを作った」を完了にすると、検証、公開判断、公開後確認の担当が地図から消えます。逆に「記事で売上を作る」まで広げると、検索、営業、商談など別の仕事が混ざります。
両端を決めたら、その間で成果物の状態が変わる箇所だけを工程にします。
記事制作を仕事の地図にする
一般的な記事制作の基本形として、テーマ設計、執筆、検証、必要な人の判断、公開後確認を分けます。公開する内容や公開先の承認要否は各社の規程と対象のリスクに合わせて決めます。以下はKirirom Digitalの社内規程ではなく、公開前に人の承認を置く場合の記入例です。
幅が狭い場合は表を横にスクロールできます
| 工程 | 担当が受け取るもの | 完了時に渡すもの | その工程で止まる条件 |
|---|---|---|---|
| 企画 | 読者の問い、公開目的、使える一次情報 | 記事の約束、証拠範囲、扱わないこと | 問いが複数ある、主要な根拠がない |
| 執筆 | 記事の約束、一次情報、既存記事との役割分担 | 本文、主張と根拠、未確認事項 | 根拠のない効果や事例が必要になる |
| 検証 | 本文、根拠、画像、リンク | 項目別の合否、修正点、残る危険 | 一つでも公開条件を満たさない |
| 人の判断 | 固定した公開候補版、検証結果、判断が要る点 | その版の承認、または差し戻し理由 | 対象版や公開先が特定されていない |
| 公開と確認 | 承認された版、公開先 | 公開URL、取得した内容、表示差分 | 承認版と公開内容が一致しない |
この表で見るのは、誰が偉いかではありません。次の担当が、何を受け取れば迷わず始められるかです。
線には「次の担当が再開できる情報」を書く
「企画から執筆へ」「検証から承認へ」と矢印を引くだけでは、引き継ぎになりません。線ごとに、最低限次の四つを書きます。
- 何が完了したか
- 何を根拠に決めたか
- 何が未確認か
- 次の担当に何をしてほしいか
記事企画から執筆へ渡す場合、「AI組織図の記事を書く」だけでは不足です。読者の問い、記事で変える判断、使える証拠、扱わない論点まで渡せば、執筆担当は同じ企画会議をやり直さずに済みます。
検証から人の承認へ渡す場合も、「確認してください」だけでは判断できません。どの版を、どこへ公開するのか、何を検証して合格したのか、何が未確認なのかを一緒に渡します。
引き継ぎの合格条件は単純です。
次の担当が、前の担当へ「何をすればよいですか」と聞き直さず、必要な根拠へ戻れること。
線が切れたときの症状を読む
仕事が止まった位置は、直すべき線を教えます。
幅が狭い場合は表を横にスクロールできます
| 症状 | 切れている可能性が高い線 | 確認すること |
|---|---|---|
| 次の担当が同じ資料を一から読み直す | 企画・調査 → 制作 | 結論、根拠、読まなくてよい範囲が渡っているか |
| 完了したはずなのに何度も差し戻される | 制作 → 検証 | 完了条件が、読みやすさや事実確認まで含んでいるか |
| 承認者の前で仕事が止まり続ける | 検証 → 人の判断 | 判断対象、選択肢、推奨、影響が絞られているか |
| 誰も検証していなかった | 制作 → 検証 | 作る担当と合否を出す担当が明示されているか |
| 公開した版が承認版と違う | 承認 → 公開 | 対象版と公開先が固定されているか |
| 公開後の誤りを誰も拾わない | 公開 → 確認 | 実際のURLを取り直す担当と完了条件があるか |
人の待ち時間が長いからといって、承認を外すとは限りません。承認者が判断できない資料を渡している、必要以上に仕事全体を止めている、判断が要る点と単なる報告が混ざっている場合があります。
戻しにくい操作は承認待ちにしつつ、影響しない別の作業は進められるように分けます。
「検証済み」でも差し戻された場所を地図へ戻す
Kiriromの記事制作では、SEO・AIO・HIOの検査を通した記事が、公開前に「初めて読む経営者には社内用語が分かりにくい」と差し戻されたことがあります。
問題は執筆担当の人数ではありませんでした。検証工程の完了条件に、会社の文脈を知らない読者が記事だけで意味を説明できるかという確認が足りていませんでした。その後、読者を先に宣言し、文脈なしで読んだ人が要点を説明できるかを検査へ加えました。
このように、差し戻しは「担当者が悪かった」で終えず、どの線に何が不足していたかへ戻します。
- 企画に読者の前提がなかったのか
- 執筆に使える言葉の基準がなかったのか
- 検証の合格条件が狭かったのか
- 人の判断で初めて分かった条件を記録へ戻していなかったのか
地図を直す対象が決まれば、次回から同じ人が同じ注意を繰り返す必要が減ります。ただし、差し戻し回数や削減時間は計測していないため、効果を数値では主張しません。
責任は工程と線の両方に置く
各工程には成果物の責任があり、各線には引き継ぎの責任があります。
- 作る担当：決めた完了条件を満たす成果物に責任を持つ
- 渡す担当：根拠、未確認事項、次の依頼をそろえる
- 受け取る担当：不足を受け入れたまま進めず、開始できる状態か確認する
- 検証担当：合否と根拠を示し、制作物を代わりに作り直さない
- 人の承認者：提示された重要な選択を判断する
- 仕事の責任者：同じ詰まりが再発したら地図と完了条件を直す
同じ人が複数を兼ねても、この責任は消えません。作った本人が検証もする場合は、少なくとも制作を終えてから検査項目に沿って別工程として確認します。
仕事の地図を作る6ステップ
1. 開始と完了を一文ずつ書く
誰が見ても発生と終了を確認できる条件にします。「営業を改善する」のような継続目標は使いません。
2. 成果物の状態が変わる箇所を並べる
受付、作成、検証、判断、実行、確認など、次の担当へ渡す理由がある箇所だけを残します。
3. 各工程に一人の主担当を置く
協力者が複数いても、次へ渡せる状態を作る責任者は一人にします。「部署全員」を担当名にしません。
4. 工程ごとの完了条件を書く
作業内容ではなく、何がそろえば次へ渡せるかを書きます。検証工程なら「確認した」ではなく、検査項目ごとのPASS・FAILと修正対象が出ている状態です。
5. 線に受け渡すものを書く
成果物だけでなく、根拠、未確認、次の依頼を付けます。会社情報の選び方は、AIが古い情報を使うのを防ぐ方法で確認できます。
6. 実際の一件を流し、止まった線を直す
図を完成品にしてから運用を始めるのではなく、現実の一件を最初から最後まで通します。追加質問、差し戻し、承認待ち、公開後の不一致が起きた位置を地図へ書き込みます。
地図が使える状態か確認する
- 開始と完了を観測できる
- 各工程に主担当と完了条件がある
- すべての線に、成果物、根拠、未確認、次の依頼がある
- 作る工程と検証する工程を区別できる
- 人の判断点は、対象と選択肢が明確になっている
- 承認待ちの一件だけを止め、他の仕事まで止めない
- 最後に、実際の結果を確認して記録へ戻す担当がいる
一つでも欠けていれば、AIや担当者を増やす前にその線を直します。AI組織図の価値は、組織が大きく見えることではなく、仕事が止まった場所と、誰が何を直すかが分かることにあります。
地図を作った後、AI部署や手順へ実装する流れは、AIネイティブ企業の作り方で確認できます。