IDE型・ターミナル型・クラウド依頼型のAIコーディングツールを作業別に選ぶ判断表

まず押さえる前提:型は製品の境界とは一致しない

ひとつの製品が複数の型にまたがることが増えています。AnthropicのClaude Code概要(2026年10月27日に閲覧)では、同じClaude Codeがターミナル、VS Code/JetBrainsなどのIDE拡張、デスクトップアプリ、Webで使えると説明されています。リポジトリのCLAUDE.mdや設定、MCPサーバーも各画面で共通とのことです。

つまり「このツールはターミナル型」と製品単位で決めるより、「今回の作業をどの形で動かすか」を決めるほうが実用的です。以下の三つの型は、編集部が作業の性質で整理した呼び方です。

• IDE型、動く場所：手元のエディタ、人の関わり方：差分をその場で見て、受け入れるか直すかを都度決める
• ターミナル型、動く場所：手元のシェル、人の関わり方：コマンド実行と結果確認を往復する。スクリプトやCIにも組み込める
• クラウド依頼型、動く場所：クラウド上の作業環境、人の関わり方：依頼して離れ、戻ってから差分やPRをレビューする

作業別の判断表

次の表は編集部の整理です。公式の推奨表ではありません。「確認頻度」は、作業中に人が判断を挟む回数の目安です。

• 関数1つの修正、命名変更、UI文言の調整、確認頻度：高い、範囲：1〜2ファイル、時間：数分、向く型：IDE型、理由：差分を見てすぐ判断できる
• 原因不明のバグ調査(ログ・再現コマンドが要る)、確認頻度：高い、範囲：不明、時間：数十分、向く型：ターミナル型、理由：実行と観察の往復が中心
• テスト追加、lint修正の横断、確認頻度：低い、範囲：複数ファイル、時間：中程度、向く型：ターミナル型、またはクラウド依頼型、理由：実行コマンドで合否が出る
• 依存パッケージの更新、機械的な置換、確認頻度：低い、範囲：広い、時間：長め、向く型：クラウド依頼型、理由：手順が決まっていて、CIで検証できる
• 小さなIssueの対応、ドキュメント更新、確認頻度：低い、範囲：限定的、時間：中程度、向く型：クラウド依頼型、理由：完了条件を文章で書ける
• 設計が決まっていない新機能、確認頻度：高い、範囲：広い、時間：長い、向く型：IDE型またはターミナル型(先に計画だけ)、理由：方針の判断が人に残る
• 未コミットの作業途中の変更に関わる作業、確認頻度：高い、範囲：手元の状態に依存、時間：問わない、向く型：IDE型・ターミナル型、理由：クラウドは手元の未コミット状態を見ない場合がある(次章)
• 定期実行・CIでの自動チェック、確認頻度：なし、範囲：固定、時間：短い、向く型：ターミナル型の非対話実行など、理由：スクリプトから呼べる

クラウド依頼型を選ぶ前に確認する制約

クラウド型は「放っておける」反面、前提条件があります。公式資料で確認できた範囲を挙げます。

Claude Codeのクラウドセッション(公式ドキュメント、2026年10月27日閲覧):

• Pro、Max、Teamプランと、一部のEnterprise席で利用できると記載されています。組織の設定で無効化されている場合もあります。
• 閉じたノートPCの外で動き続けます。一方、claude --cloud はローカルのチェックアウトではなく、GitHubリモートの現在のブランチをクローンします。ローカルにしかないコミットは、先にpushしておく必要があります。
• リポジトリのクローンとPR作成にはGitHubが必要です。GitHub以外のリポジトリはローカルバンドルとして送れますが、結果をそのリモートへpushすることはできません。
• 利用量は、通常のClaude/Claude Code利用と同じ上限を共有します。並列で走らせるほど消費が増えます。
• 一定時間操作がないと環境が失効し、実行中だったシェルコマンドやサブエージェントは再開されません。
• 完了後は、Changesの差分を画面で見て、行コメントで修正を指示できます。

GitHub Copilotのクラウド上のエージェント(GitHub Docs、2026年10月29日閲覧):

• クラウド開発環境でファイルを編集し、テストやlintを実行します。PRを作成する前に変更案を確認し、修正を依頼することもできます。
• GitHub Actions上のセッションは1リポジトリに限定され、実行時間は最大59分です。一方、クラウドサンドボックスでは同じ組織内の複数リポジトリを扱えます。どちらも同時に扱えるのは1ブランチで、1タスクにつき作成できるPRは1件です。
• 利用可否はプランと組織のポリシーに依存します。GitHub上のリポジトリのみが対象です。
• 生成物は人のレビューが前提で、セキュリティ上の問題を含むコードが出る可能性にも公式が触れています。

プランの条件や上限は変わりやすいので、導入前に各公式ページを確認してください。

迷ったときの三つの質問

判断表で二つの型に割れたら、次の順に自問します。

1. 完了を機械的に判定できますか。 テストが通る、lintが0件になる、ビルドが成功する、のように。判定できないなら、人が途中で見る必要があるため、IDE型かターミナル型に寄せます。
2. 手元の未コミットの状態や、手元にしかない情報が要りますか。 要るなら、クラウドは不利です。要らず、リポジトリに全部pushされていて、依頼文で情報が足りるならクラウド向きです。
3. 失敗したとき、やり直しの費用は小さいですか。 差分を捨てるだけで済むならクラウドに任せやすくなります。本番設定やコメントをきっかけに動く自動化が絡むなら、任せる前に範囲を絞ります。

三問とも「はい」寄りならクラウド依頼型、一問目が「いいえ」ならIDE型かターミナル型、二問目が「はい」なら手元で動かす型です。

クラウドに渡す依頼文の例(説明用)

以下は説明用の例で、実際に実行して検証したものではありません。プロジェクト名、ファイル名、コマンドは仮のものです。

目的:
 ordersモジュールの日付処理を、独自関数から標準ライブラリに置き換える。

触ってよい範囲:
 src/orders/ 配下と、そのテスト(tests/orders/)のみ。

触らないもの:
 公開APIの関数シグネチャ、設定ファイル、CI定義、依存パッケージの追加。

完了条件:
 1. `npm test -- orders` が全件成功する
 2. `npm run lint` で新しい警告が増えない
 3. 変更したファイルと理由を、PR説明に箇条書きで書く

迷ったら:
 仕様が曖昧な箇所は実装せず、PR説明の「未確認事項」に書く。

この依頼文は、先ほどの質問に対応しています。完了条件はコマンドで判定でき(質問1)、範囲が限定され(質問3)、手元の情報に頼りません(質問2)。「迷ったら書く」の一行は、勝手な判断を減らすための編集部の提案です。

渡さないほうがよい情報もあります。APIキーや顧客データなどの機密は、依頼文にも説明用データにも直接書かず、ダミー値に置き換えてください。なお、学習への利用をオフにする設定と、情報が外部に出ないことは別の話です。クラウド型では、コードが外部のクラウド環境に渡る点を、所属組織の規程に照らして確認してください。

戻ってきたときに人が見る箇所

クラウド型では、確認を後ろに寄せる分、見る場所を決めておく必要があります。

• 差分の範囲:依頼で許可していないファイルが含まれていないか。
• テストの中身:通るようにテスト側を書き換えていないか。
• 未確認事項:AIが書き残した疑問点を、先に読む。
• 自動化への影響:PRへのコメントで動くワークフローがある場合は特に注意します。Claude Codeの公式資料も、コメントをきっかけに動く自動化がある場合は、自動修正機能を有効にする前に確認するよう警告しています。

使い分けの運用例

最初から全作業を一つの型に寄せる必要はありません。たとえば次のように分けます。

• 設計と原因調査は手元(IDE型/ターミナル型)で行い、計画をファイルにまとめる。
• 計画が固まり、完了条件がコマンドで書けた段階で、クラウドに実装を依頼する。
• 戻ってきたPRは、手元で差分を見てから取り込む。

Claude Codeの公式資料にも、先にローカルでプランモードで方針を詰め、計画をリポジトリに保存してpushしてから、クラウドで実行させる流れが紹介されています。作業の性質で型を切り替える考え方と一致します。

参考にした公式資料

• Claude Code overview
• Use Claude Code in the cloud
• GitHub Copilot on GitHub.com and GitHub Mobile(GitHub Docs)