社内業務にAIを入れる前に、まず決めること

社内業務にAIを入れるとき、最初に考えるべきことは、どのAIツールを使うかではない。

先に決めるべきなのは、業務のどこをAIに任せ、どこで人間が止めるかである。

議事録を自動でまとめる。課題表のたたき台を作る。問い合わせ文を下書きする。資料の初稿を出す。

こうした使い方は、もうかなり現実的になっている。

ただし、ここで止まると、AI活用は「便利な作業代行」で終わりやすい。

社内業務で本当に必要なのは、作業を少し速くすることだけではない。

業務が前に進むこと。判断が属人化しないこと。ミスが減ること。あとから経緯を追えること。外部に出してはいけない情報や操作を守れること。

つまり、AIを業務成果につなげる設計である。

議事録や課題表は、入口にすぎない

AIを社内業務に入れると、最初に効果が見えやすいのはPMOまわりの作業である。

議事録を作る。ToDoを抜き出す。課題表を更新する。進捗会議のアジェンダを作る。関係者への確認文を下書きする。

これは便利だし、やったほうがいい。

ただ、これ自体はPMO実務である。もっと言えば、ジュニアPMOが担うことも多い作業だ。

だから、ここだけをAI化しても、社内業務の設計が変わったとは言いにくい。

大事なのは、その先である。

何を課題として記録するのか。どの状態になったらエスカレーションするのか。誰が判断すべきなのか。AIが更新してよい台帳と、人間が確認すべき台帳はどれか。

ここを決めないままAIに作業させると、課題表は増えるが、判断は進まない。

AIに任せる前に、業務の境界を決める

AIに任せやすい仕事と、任せてはいけない仕事は違う。

AIに向いているのは、情報を整理すること、候補を出すこと、抜け漏れを見つけること、文章の下書きを作ること、過去の記録から関係しそうなものを探すこと。

一方で、最後の確定をAIに渡すべきではない場面も多い。

顧客へ送信する。請求する。予約を確定する。公開する。削除する。権限を変える。契約や金額に関わる判断をする。

こうした操作は、AIが下書きや候補を作れても、人間の確認を残すべきである。

社内業務にAIを入れるときは、まずこの境界を決める必要がある。

AIがやってよいこと。

AIが提案までに留めること。

人間が必ず確認すること。

AIに読ませてよい情報。

AIに読ませない情報。

この線引きがないまま使い始めると、便利さと危なさが同時に増える。

Agentic AIは、業務が整っていないと動きにくい

最近は、Agentic AIという言葉を聞くことが増えた。

ざっくり言えば、AIが単に返事をするだけでなく、目的に向かって手順を組み立て、ツールを使い、作業を進めるような使い方である。

ただし、AIエージェントは魔法の社員ではない。

既存業務がぐちゃぐちゃなままなら、AIもぐちゃぐちゃに動く。

たとえば、どの台帳が正しいのか分からない。承認者が曖昧。例外処理が人の勘に依存している。判断基準がチャットの過去ログに埋もれている。

この状態でAIを動かしても、業務は安定しない。

AIエージェントに必要なのは、命令文だけではない。

参照するデータ、使ってよいツール、止まる条件、検証方法、人間に戻す条件が必要になる。

ここを整えることが、社内AI活用の本体である。

ループとして業務を設計する

外部の投稿で、Loop Engineeringという言葉を見た。

業務イベントを受け取り、情報を取得し、AIが処理し、検証Gateを通し、状態を記録し、人間のレビューを挟み、次のアクションへつなげる。

そういう改善ループを設計する考え方である。

この言葉自体が業界標準かどうかは、まだ分からない。

ただ、中身は社内業務にも使える。

社内業務のAI活用は、単発の自動化では足りない。

一度AIに処理させて終わりではなく、結果を確認し、状態を残し、失敗したら戻し、次の改善につなげる必要がある。

たとえば、問い合わせ対応ならこうなる。

AIが問い合わせ内容を分類する。

過去の対応例やFAQを参照する。

返信案を作る。

個人情報や金額、約束ごとが含まれる場合は人間確認に回す。

送信後は、どの問い合わせで、どの返信を使い、どこで人間が判断したかを残す。

このループがあると、AIは単なる文章生成ツールではなく、業務の一部として動ける。

PMO作業と業務設計を混ぜない

ここで注意したいのは、状態を記録すること自体はPMO作業だということだ。

議事録を取る。課題表を更新する。進捗をまとめる。

これらは大切だが、それだけでは上位の業務設計ではない。

設計として見るべきなのは、次の問いである。

どの状態を残せば、次の判断に使えるのか。

どのGateを置けば、AIの誤作動や業務事故を止められるのか。

どの例外を人間に戻し、どの処理をAIに任せるのか。

誰が最終責任を持つのか。

この問いに答えずに、AIで議事録や課題表だけを速くしても、業務全体はあまり変わらない。

社内業務にAIを入れるなら、PMO作業の自動化と、業務構造の設計を分けて考えたほうがいい。

この切り分けの根拠

PMOは、単なる議事録係ではない。

PMIのPMO研究では、PMOは組織の状況に応じて変化する存在として扱われている。プロジェクトの標準化、可視化、管理、組織的な変化への対応など、PMOの形は固定ではない。

つまり、PMOには実務作業の層もあれば、組織の運営構造を整える層もある。

議事録、課題表、進捗確認は前者に近い。

どの情報を正本にするか、どの判断をGateにするか、どの例外を人間に戻すかを決めるのは後者に近い。

AI活用で重要になるのは、この後者である。

AIリスク管理の考え方でも、同じ方向が示されている。NISTのAI Risk Management Frameworkは、AIを作って終わりではなく、設計、利用、評価の中に信頼性やリスク管理を組み込むことを重視している。

だから、この記事で言いたいのは「PMO作業をAI化しよう」ではない。

PMO作業を入口にしながら、社内業務の判断、権限、記録、検証の構造をAI前提で設計しよう、という話である。

最初に決めること

社内でAI活用を進めるなら、最初に決めることはシンプルである。

どの業務を対象にするのか。

その業務の入力は何か。

AIは何を読んでよいのか。

AIはどこまで処理してよいのか。

どの条件で人間に戻すのか。

結果をどこに残すのか。

失敗したとき、誰がどう直すのか。

この設計があるだけで、AI活用はかなり安全になる。

逆に、ここを決めずにツールだけ入れると、便利な下書きは増えるが、業務成果にはつながりにくい。

問われるのは、AIを使えるかではない

AIを使うこと自体は、これからどんどん当たり前になる。

だから差がつくのは、使えるかどうかではない。

AIが安全に働ける業務構造を設計できるか。

業務成果につながるループを作れるか。

人間の判断とAIの実行を、無理なくつなげられるか。

社内業務でAIを使うなら、まず見るべきはそこだと思う。