コーディングエージェントの実行手段を整理する

～AIの頭脳・手足・手順を分け、業務実行設計として使い分ける～

Copyright © 2026 LWP 山中 一弘

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

コーディングエージェントを使い始めると、AIがファイルを読み、コマンドを実行し、ブラウザを操作し、MCP経由で外部サービスへ接続する場面が出てきます。このとき混乱しやすいのは、コマンド、curl、ブラウザ操作、MCP、スキルが同じ「便利な機能」として見えてしまうことです。しかし実際には、それぞれが別の階層にあります。コマンド実行はもっとも基本的な手足であり、curlはその中でHTTP/API操作を担う道具です。ブラウザ操作は画面しか入口がない業務に使い、MCPは外部ツールをAIから扱う接続口です。スキルは手足そのものではなく、手足をどの順番で使うかを定義する業務フローです。

この区別が難しい理由は、AIが文章を生成するだけでなく、実際の作業環境に働きかける存在になったからです。従来は、人間が手順書を読み、判断し、操作していました。コーディングエージェントでは、AIが手順を読み、必要に応じてファイル操作、コマンド実行、ブラウザ操作、MCPを組み合わせます。したがって、AI活用の中心は「何を質問するか」から「どの業務フローを、どの実行手段で動かすか」へ移ります。

本記事では、コーディングエージェントの実行手段を「頭脳」「手足」「手順」に分けて整理します。そのうえで、API、CLI、ファイル操作、ブラウザ操作、MCP、スキルの優先順位を示し、危険操作では人間承認を挟む設計が必要であることを確認します。

本記事の対象とゴール

想定読者

• Codex、Claude Code、Gemini CLI、Playwright MCPなどのコーディングエージェントを使い始めている人。

• AIにファイル操作、コマンド実行、ブラウザ操作をさせるときの整理軸がほしい人。

• MCPとスキルの違いが曖昧で、どの作業をどの仕組みに任せるべきか判断したい人。

• 社内業務や開発作業をAIに任せる前に、危険操作と人間承認の境界を決めたい人。

本記事で得られること

1. コーディングエージェントの実行手段を、頭脳、手足、手順に分けて説明できるようになります。

2. API、CLI、ファイル操作、ブラウザ操作、MCP、スキルの使い分けを判断できるようになります。

3. 危険操作を自動実行させず、人間承認を挟む設計にできます。

本記事で扱わないこと

• 特定のAIサービスやMCPサーバーのインストール手順は扱いません。

• 個別ツールの最新仕様や料金プランは扱いません。

• 本番環境での自動実行を無条件に推奨するものではありません。

先に結論

MCPは、AIの自動化そのものではありません。MCPは、AIが外部ツールを呼び出すための接続口です。

スキルは、AIの手足そのものではありません。スキルは、AIがどの手足を、どの順番で、どの判断基準で使うかを定義する業務フローです。

コーディングエージェントを実務で使うときは、AIの能力をひとまとめに考えるのではなく、次の3つに分ける必要があります。

text

頭脳

= AIの推論、読解、判断、生成

手足

= ファイル操作、コマンド実行、curl、API操作、ブラウザ操作、MCP経由の外部操作

手順

= スキル、業務フロー、チェックリスト、プロジェクトルール

この3つを分けると、どの業務をAPIで処理し、どの業務をCLIで処理し、どの業務をブラウザ操作に任せ、どの業務をスキル化するかを判断しやすくなります。

第1章 コーディングエージェントの手足とは何か

この章では、コーディングエージェントにおける「手足」という言葉を定義します。ここでいう手足とは、AIが作業環境へ実際に働きかける実行手段です。

1.1 従来のチャットAIとの違い

従来のチャットAIは、質問に答えたり、コードを提案したり、手順を説明したりすることが中心でした。人間はAIの回答を読み、必要な操作を自分で実行していました。

コーディングエージェントでは、この関係が変わります。AIがファイルを読み、コードを書き換え、コマンドを実行し、テスト結果を確認し、必要に応じて修正します。

つまり、AIは文章を返すだけではなく、作業環境に対して実際に働きかけます。

1.2 手足の代表例

代表的な手足には、次のものがあります。

text

ファイル操作

コマンド実行

プログラム実行

curlによるHTTP/API操作

ブラウザ操作

MCPサーバー経由の外部ツール操作

テスト、ビルド、検証の実行

これらはすべて、AIが現実の作業環境に対して何かを行うための実行手段です。ただし、すべてが同じ階層にあるわけではありません。コマンド実行、curl、MCP、スキルは、それぞれ役割とレイヤーが異なります。

第2章 コマンド実行は最も基本的な手足である

この章では、コマンド実行の位置づけを整理します。コマンド実行は、コーディングエージェントが開発環境を動かすための基礎です。

2.1 コマンド実行でできること

PowerShell、bash、zsh、cmd、Python、Node.js、Git、npm、curlなどを実行することで、AIはローカル環境や開発環境に働きかけます。

たとえば、次のような作業です。

bash

git status

npm install

npm test

python script.py

curl https://example.com

コマンド実行によって、AIは単にコードを書くのではなく、そのコードを実際に動かし、結果を確認できます。

2.2 実行と検証のループ

コードを提案するだけなら、チャットAIでもできます。コーディングエージェントの価値は、実行し、ログを見て、失敗を確認し、修正するループを回せる点にあります。

このループは、次の形で整理できます。

text

コードを書く

↓

コマンドを実行する

↓

ログを読む

↓

失敗原因を判断する

↓

コードまたは設定を修正する

↓

もう一度実行する

コマンド実行は、AIが開発環境を動かすための基礎的な手足です。

2.3 実行時の確認点

コマンド実行では、実行対象、作業ディレクトリ、権限、環境変数、ネットワークを確認します。

確認すべき点は次のとおりです。

4. どのフォルダで実行しているか。

5. どのコマンドを実行したか。

6. 標準出力とエラー出力に何が出たか。

7. 実行結果がファイルや環境へ何を変更したか。

8. 再実行してよい操作か。

危険なコマンドは、AIにそのまま自動実行させず、人間承認を挟む必要があります。

第3章 curlはAPI操作・通信確認の中核ツールである

この章では、curlの位置づけを整理します。curlはMCPと同列の別概念ではなく、コマンド実行の中でHTTP/API操作を担う重要な道具です。

3.1 curlで扱う対象

curlは、ブラウザを開かずにHTTPリクエストを直接送るための道具です。APIの疎通確認、レスポンス確認、Webhook確認、認証ヘッダーの確認、外部サービスとの通信テストなどに使えます。

たとえば、次のような用途です。

bash

curl https://api.example.com/users

curl -X POST https://api.example.com/login

curl -H "Authorization: Bearer TOKEN" https://api.example.com/me

curlの重要性は、画面操作を経由せず、システムの入口を直接叩ける点にあります。

3.2 APIが画面操作より安定する理由

Web業務やシステム連携では、ブラウザで画面を操作するよりも、APIを直接呼び出した方が安定する場合があります。画面レイアウトの変更に影響されず、入力と出力が明確だからです。

curlは、コマンド実行の中でAPI操作を担う重要ツールです。

text

コマンド実行

└ curl

  └ HTTP/API操作

3.3 通信確認の観点

curlでは、URL、HTTPメソッド、認証、ヘッダー、リクエスト本文、ネットワークを確認します。

確認すべき点は次のとおりです。

9. URLが正しいか。

10. GET、POST、PUT、DELETEなどのメソッドが正しいか。

11. 認証トークンやAPIキーを安全に扱っているか。

12. レスポンスのステータスコードが何か。

13. レスポンス本文に期待した値があるか。

認証情報や個人情報を含むcurlコマンドは、記事やログへそのまま残さないようにします。

第4章 ファイル操作とプログラム実行を分けて考える

この章では、ファイル操作とプログラム実行を整理します。どちらもAIの手足ですが、役割は異なります。

4.1 ファイル操作はラッパー経由で行われる

コーディングエージェントがファイルを読む、書く、編集する、検索する、削除する場合、AI自身が直接C言語のファイル操作関数やWindows APIを呼び出しているわけではありません。

通常は、エージェントに用意されたファイル操作用のツールやAPIを経由します。

概念的には、次のような構造です。

text

AI

↓

エージェントのファイル操作ツール

↓

Node.js / Python / Rust / Go などのランタイム

↓

標準ライブラリ

↓

OS API / システムコール

↓

ファイルシステム

AIが直接 fopen や CreateFile を呼んでいるわけではありません。多くの場合、AIは「このファイルを読め」「この範囲を書き換えろ」「このディレクトリを一覧せよ」という高水準のツールを呼びます。

VBAで例えるなら、Win32 APIを直接宣言して呼ぶというより、FileSystemObjectのような高水準オブジェクトを使っているイメージに近いです。

4.2 プログラム実行は処理をコードへ逃がす仕組みである

AIに毎回すべてを考えさせるのではなく、処理そのものはプログラムに任せる方が効率的な場合があります。

たとえば、CSVの集計、ファイル名の一括変更、Excelデータの変換、APIレスポンスの整形などは、AIが都度処理するより、PythonやNode.jsなどのスクリプトにした方が速く、安定します。

この場合、AIの役割は次のようになります。

text

処理方針を考える

スクリプトを書く

スクリプトを実行する

結果を確認する

エラーがあれば修正する

つまり、プログラム実行は、AIが処理を直接抱え込むのではなく、コードという実行単位に切り出す仕組みです。

4.3 ファイル操作の安全確認

ファイル操作では、対象パス、文字コード、同名ファイル、上書き、削除の扱いを先に確認します。

安全に実行するには、次を守ります。

14. 移動、リネーム、削除の前に旧パスと新パスを確認します。

15. 上書き前にバックアップまたは退避先を決めます。

16. 生成物と原本を分けます。

17. 一括操作では対象一覧を先に出します。

AIにファイル操作をさせる場合、最も危険なのは「対象を誤ること」です。したがって、対象範囲を狭く固定することが重要です。

第5章 ブラウザ操作とMCPの役割を分ける

この章では、ブラウザ操作とMCPを分けて整理します。ブラウザ操作はWeb画面を扱う手足であり、MCPは外部ツールをAIから扱うための接続口です。

5.1 ブラウザ操作はWeb画面を扱う手足である

Webシステムには、APIが用意されていない場合があります。また、APIがあっても仕様が公開されていない、認証が複雑、実際の業務が管理画面操作を前提にしている、といったケースもあります。

その場合に必要になるのがブラウザ操作です。

Playwrightのようなブラウザ操作ツールを使うと、AIはページを開く、ボタンをクリックする、フォームに入力する、検索する、ファイルをダウンロードする、といった操作を行えるようになります。

ここで重要なのは、Playwright MCPのような仕組みでは、単純に画面画像を見て座標クリックしているわけではない点です。

多くの場合、Webページ内のボタン、入力欄、リンクなどを構造情報として取得し、AIがそれを判断して操作します。

text

右上をクリックする

ではなく、

text

ログインボタンを押す

検索欄に入力する

保存ボタンをクリックする

という意味ベースの操作になります。

この方式は、通常の座標クリック型RPAより安定しやすいです。画面サイズや多少のレイアウト変更に左右されにくく、Webページの部品を意味で扱えるからです。

5.2 MCPは外部ツールをAIから扱うための接続口である

MCPは、AIが外部ツールやシステムを呼び出すための接続方式です。

MCP自体が特定の作業をするというより、AIが外部機能を共通的な形式で呼び出せるようにするための仕組みです。

たとえば、MCPサーバーには次のようなものがあります。

text

Playwright MCP

= ブラウザ操作

Filesystem MCP

= ファイル操作

Database MCP

= データベース操作

GitHub MCP

= GitHub操作

Slack MCP

= Slack操作

MCPは「AIの手足そのもの」というより、「AIに手足を接続するための規格」と考えると分かりやすいです。

ただし、MCPを使えば何でも安全に操作できるわけではありません。どのフォルダを許可するか、どのAPIを許可するか、どの操作を禁止するか、といった権限設計が重要です。

第6章 スキルは手足ではなく業務フローの実行定義である

この章では、スキルの位置づけを整理します。スキルは実行手段そのものではなく、実行手段を使う順序と判断基準を定義するものです。

6.1 スキルはレイヤーが違う

コマンド、curl、ファイル操作、ブラウザ操作、MCPは、AIが何かを実行するための手足です。

一方、スキルは「その手足を使って、どの業務を、どの順番で、どの基準で進めるか」を定義するものです。

従来の業務フローは、人間が読んで実行するものでした。

text

人間が手順書を読む

↓

人間が資料を確認する

↓

人間が判断する

↓

人間が操作する

↓

人間が成果物を作る

スキルでは、この業務フローに相当するMarkdownなどをAIが読みます。

text

AIがスキルを読む

↓

AIが資料を確認する

↓

AIが判断する

↓

AIが必要な手足を使う

↓

AIが成果物を作る

スキルとは、人間が読んで実行していた業務フローを、AIが読んで実行できる形に変換したものです。

6.2 スキルはAIを業務部品化する

スキルの本質は、単なるプロンプト集ではありません。

従来のプログラムでは、処理の部品は関数、API、ライブラリ、オブジェクト、メソッドでした。プログラム本体が、それらの部品を呼び出して処理を進めます。

text

プログラム本体

↓

関数を呼ぶ

↓

APIを呼ぶ

↓

ライブラリを呼ぶ

↓

オブジェクトのメソッドを呼ぶ

↓

決められた処理を実行する

一方、スキルでは、業務フローの各工程をAIが実行します。

text

スキル本体

↓

業務フローを読む

↓

各工程でAIが判断する

↓

必要に応じてファイルを見る

↓

必要に応じてコマンドを実行する

↓

必要に応じてMCPを使う

↓

状況に応じて成果物を作る

プログラムの部品は、基本的に決められた入力に対して、決められた処理を返します。一方、スキルの部品は、AIによる判断、読解、生成、操作です。

この点に、スキルの実務上の価値があります。

第7章 プログラム化できない業務をスキルが扱う

この章では、スキルが有効な業務領域を整理します。スキルは、完全なプログラムにするほど固定的ではないが、人間が毎回ゼロから考えるほど自由でもない業務に向いています。

7.1 スキルが扱いやすい業務

従来の自動化は、プログラム化できる業務に強く、曖昧な判断を含む業務には弱いものでした。

たとえば、次のような業務です。

text

見積書の妥当性確認

議事録からの論点抽出

要件定義書の整理

顧客向けメールの作成

資料構成の検討

Excel納品前チェック

動画編集前の素材確認

これらは、完全に自由な作業ではありません。一定の手順や観点があります。

しかし、完全なプログラムにするには曖昧さが多すぎます。自然文を読み、状況を判断し、例外を扱い、相手に合わせて表現を調整する必要があるからです。

7.2 中間領域としてのスキル

スキルは、この中間領域に強いです。

text

完全なプログラムにするほど固定的ではない

しかし、人間が毎回ゼロから考えるほど自由でもない

こうした業務を、AIが実行可能な業務フローとして定義できる点に価値があります。

第8章 実行手段の優先順位を決める

この章では、AIに業務を実行させるときの優先順位を整理します。重要なのは、すぐにブラウザ操作へ進まないことです。

8.1 安定性と再現性で選ぶ

業務をAIに実行させるとき、すぐにブラウザ操作を使えばよいわけではありません。

実務上は、安定性と再現性を考えて、次の優先順位で考えるのが自然です。

text

APIがあるならAPIを使う

CLIがあるならCLIを使う

ファイル入出力で済むならファイル操作を使う

画面操作しかないならPlaywrightなどのブラウザ操作を使う

判断が必要ならスキルで手順化する

危険操作は人間承認を挟む

APIは画面操作より安定します。CLIは開発環境やローカル操作に強いです。ファイル操作は成果物や設定の読み書きに必要です。ブラウザ操作は、Web画面しか入口がない場合に有効です。MCPは、それらの外部操作をAIから扱いやすくする接続口です。スキルは、それらを業務フローの中でどう使うかを定義します。

8.2 判断軸

実行手段を選ぶときは、次の順で判断します。

18. 入力と出力が明確ならAPIを優先します。

19. ローカル環境や開発環境の操作ならCLIを優先します。

20. 成果物や設定ファイルの読み書きならファイル操作を優先します。

21. Web画面しか入口がないならブラウザ操作を使います。

22. 外部ツールをAIから共通形式で呼びたいならMCPを使います。

23. 判断を含む繰り返し業務ならスキル化します。

このように整理すると、AI活用は単なる「MCPを使うかどうか」ではなく、「どの作業にどの実行手段を使うか」という設計問題になります。

第9章 危険操作には人間承認が必要である

この章では、AIに手足を与えるときの安全設計を整理します。AIができることが増えるほど、操作の境界を決める必要があります。

9.1 危険操作の例

特に注意すべき操作は次のようなものです。

text

ファイル削除

上書き保存

本番環境への反映

メール送信

外部公開

決済、支払い

顧客情報の取得

個人情報の取り扱い

ログイン済みブラウザでの外部サイト操作

これらは、完全自動化するのではなく、人間承認を挟む設計が必要です。

9.2 実行レベルを分ける

AI活用では、すべてを自動実行させることが正解ではありません。

text

提案のみ

下書き作成まで

人間承認後に実行

テスト環境だけ実行

特定フォルダ内だけ操作

削除は禁止

送信前に確認

このように、実行レベルを分けることが重要です。

9.3 実行前の確認範囲を決める

危険操作を扱う場合は、実行前に対象範囲と承認範囲を決めます。

確認すべき点は次のとおりです。

24. 対象ファイル、対象サービス、対象アカウントが明確か。

25. バックアップや退避先が必要か。

26. 実行前に対象一覧を出しているか。

27. 実行後に結果を確認できるか。

28. 人間承認が必要な操作を自動実行に含めていないか。

AIに実行手段を与えるほど、業務は速くなります。同時に、誤操作の影響も大きくなります。だからこそ、承認、範囲制限、ログ、確認手順を設計に含める必要があります。

第10章 これから重要になるのは業務実行設計である

この章では、記事全体の結論をまとめます。今後のAI活用では、AIに何を質問するかだけでなく、どの業務プロセスを、どの実行手段で動かすかを設計する必要があります。

10.1 AIに何を聞くかから業務フロー設計へ

今後のAI活用では、AIに何を質問するかだけでは不十分になります。

重要になるのは、AIにどの業務プロセスを、どの手順で、どの操作手段を使って実行させるかです。

そのためには、次の設計が必要になります。

text

どの業務をAIに任せるか

どの業務をプログラム化するか

どの業務をスキル化するか

どこでコマンドを使うか

どこでcurlやAPIを使うか

どこでブラウザ操作を使うか

どこでMCPを使うか

どこで人間承認を挟むか

従来のAI活用は、AIに質問することが中心でした。しかし、コーディングエージェントやMCP、スキルが出てくると、AIは作業環境に対して実際に働きかける存在になります。

その結果、AI活用の中心は次のように変わります。

text

AIに何を聞くか

↓

AIにどの業務フローを実行させるか

これは、単なるチャットAIの延長ではありません。AIを業務実行基盤として使うための、新しい設計思想です。

10.2 まとめ

コーディングエージェントを理解するには、AIの頭脳、実行手段としての手足、業務フローとしての手順を分ける必要があります。

MCPは、AIに外部ツールを接続する仕組みです。スキルは、外部ツールをどの順番で、どの判断基準で使うかを定義する業務フローです。コマンド実行、curl、ファイル操作、ブラウザ操作は、それぞれ異なる手足です。

この整理を持つことで、AI活用は「何となく便利な自動化」ではなく、業務実行設計になります。どこをAPIに任せるか、どこをCLIに任せるか、どこでブラウザ操作を使うか、どこで人間承認を挟むかを決められるようになります。

コーディングエージェントの価値は、AIが考えることだけにありません。考えた内容を、適切な手足と手順で実行し、検証し、必要に応じて修正できることにあります。