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