「AGIって、うちの業務でどこまで使えるんですか」。社内でそう聞かれて、答えに詰まったことはないでしょうか。
用語の定義は人によって違い、目に入る事例は成功例ばかりです。そのまま議論だけが進み、任せる範囲は決まらない。そういう状態でこの記事にたどり着いた方が、多いのではないかと思います。
この記事は、用語の定義には立ち入りません。AGIの業務活用がいま実務でどこまで進んだかを、担える工程と担えない工程に分けて整理します。根拠は外部プロダクトの公式ドキュメントと、運営元WEBMARKSの運用実測です。用語そのものの整理は、別記事『AIエージェントとは｜3条件で見分け、任せる前に決める3つ』が引き受けます。
本記事の検証環境：Claude Sonnet 5 / Claude Code v2.1.x / macOS 15 / 2026-07-28検証。常駐ジョブの本数だけは、2026-08-20に同じコマンドで測り直しました。
こんなふうに調べていませんか
- 「AGIで仕事が変わる」と言われたが、自社のどの工程が対象なのか分からない
- AIエージェントを試してはみたが、どこまで任せてよいか判断がつかない
- 社内にAI社員の体制図はあるが、実際に動いているのか確かめる方法を知らない
この記事を読み終えたときに手に入るもの
- 任せられる工程と、人に残る工程を自分の言葉で線引きできるようになります
- 業務プロセスごとの到達度を、表と図で見分けられるようになります
- 到達度を主張ではなく実測で確かめる3つの見方が手に入ります
結論30秒でわかる、この記事の結論
- AGIの業務活用は、目標を渡すだけで完了まで進む工程と、要所で人の判断に戻ってくる工程に分かれます。
- 境界を分けるのは技術の新しさではなく、結果を検証できるかと、止める場所を決めてあるかの2点です。
- 到達度は工程ごとに測ります。1つの数字にまとめると、進んだ工程も遅れた工程も見えなくなります。
進行役は3人です。若葉さん（Web担当2年目）が用語のそもそもを聞き、大森部長（マーケ部長）が投資と体制を判断し、鈴木さん（本誌監修）が答えます。あなたに近い立場の人の質問から読んでいただいて構いません。
01AGIの業務活用は、AIエージェントで見ると何と何に分かれるんですか？
若葉さん「AGIがどこまで来たか」って、そもそも何を測れば答えになるんでしょうか。
鈴木さん技術の名前ではなく、工程で測ると整理しやすくなりますよ。同じ仕組みでも、任せて最後まで進む工程と、途中で人に戻ってくる工程があります。まずそこを分けます。
結論を先に置きます。AGIの業務活用は、大きく2つに分かれます。目標を渡すだけで完了まで進む工程と、要所で人の判断に戻ってくる工程です。
前者は、情報収集・下書き作成・検証基準が明確なコード修正で実務投入が進んでいます。後者は、常駐オペレーション・最終責任を伴う操作・例外対応で足踏みしています。
この章のまとめ
進み具合は「AGI全体」ではなく工程ごとに測ります。物差しは、検証できるかと、止める場所があるかの2点です。
02AGIの業務活用で、AIエージェントには、いま何なら任せられるんですか？
実務投入がいちばん進んでいるのは、成功の基準を人がその場で検証できる工程です。
たとえばGitHub Copilot coding agentには、6種類のタスクを割り当てられます（出典: GitHub公式ドキュメント）。内訳は、バグ修正、段階的な新機能実装、テストカバレッジの向上、ドキュメント更新、技術的負債の解決、マージコンフリクトの解決です。
並べてみると、共通点が見えます。どれも「直ったかどうか」を人がその場で判定できる作業です。
割り当てた課題は、リポジトリを調べるところから始まります。実装計画を立て、ブランチへ変更を反映するところまで自動で進みます（出典: GitHub公式ドキュメント）。人の出番は、その計画と差分をレビューする段階です。
検証の基準がはっきりしている工程ほど、任せられる幅は広がります。逆に言えば、基準があいまいな工程を先に渡しても、確認の手間だけが増えます。
自社で最初に渡す工程を選ぶときは、「出てきたものを誰が、何を見て合否判定するか」を先に書いてみてください。書けない工程は、まだ渡す順番ではありません。
03AGIの業務活用でMCPを入れると、AIエージェントに任せてよい範囲まで広がるんですか？
先に答えを書きます。広がるのは、手が届く先だけです。任せてよい範囲は、別に決めます。
MCP（Model Context Protocol・外部システムをAIに触らせるための共通の口）は、外部システムに接続するための標準規格です（出典: MCP公式）。カレンダーやデータベースといった複数の接続先を、アプリごとに個別実装しなくてもつなげます。
対応クライアントはClaude・ChatGPT・VS Codeなど幅広い顔ぶれです。公式サイトも、幅広いエコシステムに支えられていると説明しています。
ここで足されるのは、判断力ではありません。届く先が増えるだけです。
つなげる先が増えると、任せられる作業の種類は広がります。ただし、つないだ先で何をしてよいかは、別に決める話です。次の章から扱う「止める場所」が効いてくるのは、まさにここです。
04AGIの業務活用でも、AIエージェントに任せられない工程が残るのはなぜですか？
大森部長残る工程は、いずれ技術で消えるものですか。消えるなら、いま体制を組むのは早いと思うのですが。
鈴木さんいえ、そこは逆です。残る前提で組んだほうが、結局は早く広げられます。理由は技術ではなく、検証とガードレールの整備コストにあります。
大森部長整備が追いつかない工程ほど、投入が遅れるということですね。
鈴木さんはい。そこは費用と体制の設計で埋める部分になります。
担えない工程にも共通点があります。
Anthropicは、成功した実装の多くについてこう述べています。複雑なフレームワークではなく、単純で組み合わせ可能なパターンで作られていた、と（出典: Anthropic公式）。同じ文書では、隔離環境での十分なテストと適切なガードレールも推奨されています。
裏を返すと、検証とガードレールの整備が追いつかない工程ほど、実務投入が遅れます。構造的に人へ残る場面は3つです。常駐で動かし続ける運用、送信・公開・削除・決済のように対外的に確定する操作、そして想定外の入力への例外対応です。
常駐で動かし続ける運用は、この整備コストがとりわけ高い工程です。設定ファイルを書いた事実と、いま読み込まれている事実は、別に数えます。
運営元WEBMARKSは、常駐ジョブの状態をlaunchctlで数え直しています。2026-07-28時点は、定義8本に対して読み込み済み1本でした。同じコマンドを2026-08-20に流し直すと、定義20本に対して読み込み済み16本です。
差が縮んだのは、新しい仕組みを足したからではありません。書いたまま読み込んでいなかったものを、1本ずつ入れ直した結果です。そして読み込み済みになっても、それは「動く場所に置いた」までの話です。出力を確認する手順まで揃って、はじめて任せたと言えます。
3つ目の例外対応は、とりわけ見落とされがちです。取り込んだ文書やページに、指示らしき文字列が紛れ込むことがあります。それを実際の指示と取り違える恐れがあるためです。
対策は、取り込む情報源をあらかじめ区分しておくことです。外部からの入力を指示として扱わない設計が要ります。
この章のまとめ
人に残る工程は、技術が追いついていないから残るのではありません。検証とガードレールの整備コストが高いから残ります。
05AGIの業務活用でAI社員に任せる前に、どこで止まるかをどう決めておくんですか？
大森部長事故が起きてから止め方を考えるのでは遅い、というのは分かります。では、任せる前に何を決めておけばいいのでしょうか。
鈴木さん止める地点です。実行の直前に、人へ確認を挟む場所を置いておく。あとから足す機能ではなく、任せる前に選ぶものだと考えています。
Claude Codeでは、ツール実行の直前にPreToolUseフックを発火できます（出典: Claude Code公式ドキュメント）。返ってくる判定はallow・deny・askの3つです。
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "ask",
"permissionDecisionReason": "送信・公開系の操作は人が確認します"
}
}この動きを決めているのがpermissionDecisionです。askなら実行前に人へ確認が挟まり、denyならそこで止まります。allowのときは、確認を挟まずにそのまま実行されます（出典: Claude Code公式ドキュメント）。
運営元WEBMARKSのAI社員も、この地点を共通の入口にしています。役割ごとにAI社員を何体動かしても、送信・公開・削除・決済にあたる操作は、実行の直前で人に戻す運用です。止める場所を役割の数だけ作らないことが、運用側の設計にあたります。
同じくGitHub Copilot coding agentでは、Pull Requestの作り方を選べます（出典: GitHub公式ドキュメント）。差分をレビューしてから作る反復型と、即座に作成させる直接型があります。反復型を選ぶこと自体が、対外的に確定する前に人の確認を挟む設計です。
06うちの業務プロセスだと、AGIの業務活用はAIエージェントでどこまで届いていますか？
大森部長うちに当てはめて見たいのですが、専任は置けません。マーケ部の3人で回している状態です。
鈴木さんそれなら、全部を並べる必要はありません。業務プロセスを行に分けて、2つの軸のどこに載るかだけ先に決めてください。載った区画が、そのまま打ち手になります。
大森部長分かりました。まず情報収集と下書きの行から埋めてみます。
進み具合は、業務プロセスの種類でかなり違います。
まず、運営元WEBMARKSの表を見本として出します。自社の表を作るときは、実例の欄を自社の道具に、右端の欄を自社の担当者名に置き換えてください。
| 業務プロセス | 到達度（2026-08-20時点） | 実例 | 人に残る判断 |
|---|---|---|---|
| 情報収集・下書き作成 | 実務投入が進んでいる | Claude Codeで資料を読み下書きを作る運用（本記事の執筆体制も同様） | 採用するか |
| ソフトウェア開発 | 実務投入が進んでいる（レビュー前提） | GitHub Copilot coding agentへの課題割り当て | マージするか |
| カスタマーサポート | 実例はあるが自社は未導入 | Anthropicが向く領域の例として挙げる分野 | 対応を確定するか |
| 常駐オペレーション | 読み込みは進み、検証はこれから | WEBMARKSのlaunchdジョブ（定義20本・読み込み済み16本、2026-08-20実測） | 稼働を止めるか続けるか |
| 意思決定・最終承認 | 構造的に人に残る | 送信・公開・削除・決済の最終判断 | 誰が確定させるか |
自社の表は、行を先に決めます。次に、その行が2つの軸のどこに載るかを書き込みます。縦は結果をすぐ検証できるか、横は対外的に確定する操作を含むかです。表に写すのではなく、載せた区画から打ち手を読みます。
見本の表の下2行は前章の担えない工程と、上2行は担える工程と重なります。
この章のまとめ
自社の到達度は、業務プロセスの行に分けて書き出します。行ごとに「人に残る判断」を書けたら、線引きは終わっています。
07AGIの業務活用で、AIエージェントの実例はあるが未確認の工程はどう扱いますか？
大森部長見本の表で1行だけその旨の注記が付いています。うちはそこから始めたいのですが、任せられますか。
鈴木さんそこは正直に言うと、まだ答えを持っていません。うちで顧客対応に投入した実績がないので、他社の例を自分の実測のように話すことができないんです。
大森部長分からないと言ってもらえるほうが、こちらは判断しやすいです。
この欄の扱い方が、実測を掲げる記事といわゆる事例紹介との分かれ目になります。
「カスタマーサポート」をとしたのは、Anthropicの文書が向く領域の例として挙げている一方で、運営元WEBMARKSに顧客対応へ投入した実績が無いためです。世の中に実例があることと、自社で検証済みであることは、別の情報として扱います。
表の各行は、この先の号で1行ずつ深掘りしていきます。外部ツールとの接続はMCPの選び方、常駐オペレーションは自動化の設計、意思決定の残し方はガバナンス。そうやってテーマ別のカテゴリに分けています。本記事は、その一覧を俯瞰する入口の位置づけです。
08AIエージェントを役割ごとに分けると、AGIの業務活用の何が変わるんですか？
複数のエージェントに役割を分けて任せる動きも、実務段階に入っています。
OpenAI Agents SDKには、役割の異なるエージェントへ作業を渡すHandoffsという仕組みがあります（出典: OpenAI公式）。コーディング・レビュー・文書作成のように役割を分けたエージェントを、隔離した作業領域で組み合わせる。そうした使い方が想定されています。
Claude Codeにも、特定の作業だけを担当するサブエージェントを定義する仕組みがあります。呼び出せる道具をタスクごとに制限し、独立した文脈と権限のもとで動かします（出典: Claude Code公式ドキュメント）。役割を絞ると、任せる範囲と確認する範囲を切り分けられます。
AGI Journal自体も、この層を使っています。執筆・原典照合・批評を、それぞれ別の役割に分けています。姉妹メディアAIO Journalから引き継いだ体制です。
変わるのは、確認の回数です。1体に全部を任せると、検証も一度で済ませがちになります。役割を分けると、次の担当が前の担当の出力を検証してから引き継ぎます。確認が、工程の数だけ増えます。
変わらないものもあります。役割を分けても、対外的に確定する操作は人のところへ来ます。分担は担える工程を広げる手段であって、担えない工程を消す手段ではありません。
09AGIの業務活用の到達度は、AI社員が動いているかをどう確かめるんですか？
若葉さん「うちはもう動いています」と言われたら、どこを見れば本当かどうか分かるんでしょうか。
鈴木さん見る場所は3つです。実行ログ、成果物の数、そして経過した期間ですね。決まった日と、いま確認している日の間隔まで見ます。ここを飛ばすと、始まったばかりの体制を定着済みと読んでしまいます。
この記事を書くにあたって運営元WEBMARKSが行った確認は、次の3種類です。
- 実行ログ・稼働状態を見る：定義されているかどうかではなく、いま読み込まれているかを見ます。
launchctl listでジョブを数えるのが一例です。設定ファイルがあるだけでは、稼働の証拠になりません - 成果物を数え直す：「公開されている」という主張は、実際のURL数やファイル数で数え直して確かめます。要約ツールが返した数字も、そのままでは一次情報として扱いません
- 経過期間を見る：仕組みが決まった日と、いま確認している日との間隔を見ます。体制があることと、定着していることは別ものです
この見方は、実際に誤りを防いだことがあります。
2026-07-28のことです。社内のAIエージェントが古い記録だけを根拠に、姉妹メディアを「1本も公開されていない」と報告しました。ところがsitemap.xmlを数え直すと、実際には251本が公開済みでした。
原因は、主張を検証せずに引き継いだことです。以降、稼働を否定する報告は、本番の状態を数えてから出す運用に変えました。
この章のまとめ
到達度は主張では決まりません。ログ・成果物の数・経過期間の3つを見れば、自分で判定できます。
10AGIの業務活用に向けて、AI導入でつまずく3つの思い込みは、どこが間違っているんですか？
社内で議論がかみ合わないときは、前提の置き方がずれています。よく出るものが3つあります。
思い込み1：動いて見えれば、実務に定着している
体制が定義されていることと、検証を終えて定着していることは、別の話です。
運営元WEBMARKSが7部署・30名の役割定義を統合したのは、2026-06-24です。そしてこの記事の最初の検証日は2026-07-28です。統合した直後の体制図だけを見て、長期運用済みと誤読しないよう注意が要ります。
思い込み2：1つの数字で全体の到達度が分かる
進み具合は工程ごとに違います。だから1つの指標では表せません。
情報収集・下書き作成では実務投入が進む一方、常駐オペレーションは検証がこれからです。一括りにすると、進んだ工程を低く見積もるか、遅れた工程を高く見積もることになります。工程を分けずに語る資料は、そこで一度疑ってよいと考えます。
思い込み3：検証は一度やれば十分
実測は、一時点の記録です。
この記事も、常駐ジョブの本数は初回の検証から更新までのあいだに動きました。だから同じコマンドで測り直して差し替えています。freshness: watchの記事として、四半期ごとに棚卸しします。古い検証結果をそのまま使い続けるのは危険です。
| よくある思い込み | 実際に起きていること |
|---|---|
| 動いて見える＝実務に定着している | 体制の定義と検証済みの稼働は別（統合から約1か月） |
| 1つの数字で到達度を語れる | 工程ごとに違う（情報収集は先行、常駐は検証がこれから） |
| 検証は一度やれば十分 | 実測は一時点の記録。watchラベルで棚卸しする |
11AGIの業務活用に向けたAI導入の前に、何を確認しておけばいいんですか？
ここまでの内容を、着手前に自分の業務へ当てはめるための項目にまとめます。「いいえ」が1つでもあれば、着手ではなく検証のほうを先に進めてください。
- この工程の進み具合を、主張ではなく実測で確認したか
- 常駐運用にするなら、稼働状況をログで確認する手順を用意したか
- 送信・公開・削除・決済の最終判断者を1人に決めたか
- 失敗したときに止める地点を、実行前フックなどで設計したか
- 検証環境の記載日を確認し、古い前提で判断していないか
- 「動いている」という報告を、出力やログで裏取りしてから使っているか
- 到達度を工程ごとに分けて記録し、1つの数字でまとめていないか
12よくある質問
AGIとAIエージェントは同じ意味ですか
呼び方はメディアや文脈で揺れていて、統一された定義はまだありません。本メディアでは業務プロセスの観点から、目標を渡すと手順を自分で決めて動く仕組みを指す語として扱っています。社内で議論するときは、語の定義をそろえるより先に「どの工程を、誰の確認つきで任せるか」に合意したほうが早く進みます。呼び名が違っても、任せる範囲の線が引ければ運用は回ります。用語そのものの整理は、別記事の定義に譲ります。
個人でもAGIを業務に使えるようになりますか
用途によります。情報収集や下書き作成のように成果をすぐ判定できる工程なら、個人でもすでに使えます。常駐運用や、複数の業務にまたがる導入には、検証とガードレールの設計知識が要ります。まずは、出てきたものを自分がその場で合否判定できる工程から始めてください。判定の手順を書けない工程を先に渡すと、確認の手間だけが増えて続かなくなります。渡す順番を間違えなければ、個人の規模でも効果は出ます。
常駐オペレーションが検証段階なら、いま着手するのは早いですか
工程によります。情報収集・下書き作成やソフトウェア開発なら、着手を待つ理由はありません。常駐オペレーションは、稼働状況を確認する手順を先に用意してから広げてください。手順が無いまま広げると、動いていない部分に誰も気づけなくなります。本記事で使ったように、定義した数と読み込まれている数を別々に数えるだけでも、気づける状態にはなります。数え方が決まってから広げる、の順番です。
この記事の到達度は、今後も同じですか
変わります。freshness: watchのラベルを付けた記事として、四半期ごとに検証環境と数値を棚卸しします。実際、常駐ジョブの本数は初回の検証から今回の更新までのあいだに動いたため、同じコマンドで測り直して差し替えました。読むときは本文冒頭の検証環境の記載日を見てください。日付が古ければ、その数値は鵜呑みにせず、記事に書いてあるコマンドで自分の環境を数え直すほうが確実です。
13まとめ｜今日やる3つのこと
分け目は、結果を検証できるかと、止める場所を決めてあるかの2点でした。到達度は工程ごとに測ります。自社の表に落とすところまで、この順で進めてください。
今日この順で手をつけます
業務プロセスを行に分けて書き出す
到達度は工程ごとにしか測れないためです
行ごとに「人に残る判断」を書く
誰が確定させるかが決まれば、任せる範囲も決まります
稼働を数える手順を用意する
定義ではなく実行ログで見る癖が、報告の質を変えます
AI検索では、こう聞かれています
AGIって、いま業務のどこまで任せられるんですか？
「AIエージェントには、いま何なら任せられるんですか？」の章で説明しています
AIエージェントに任せられない工程は、どこですか？
「AGIの業務活用でも…任せられない工程が残るのは」の章で3つに整理しています
AGIの業務活用の到達度は、どうやって確かめるんですか？
「AGIの業務活用の到達度は、AI社員が動いているかを」の章に3つの見方があります
任せた先で事故が起きたら、どこで止まるんですか？
「AI社員に任せる前に、どこで止まるかをどう決めておくんですか？」の章で扱っています
次に読むなら、この記事です
