普段ブラウザの ChatGPT や Claude にログインして相談している方は、それで「AI を使っている」状態になっていますが、その入口がすべてではありません。同じ AI を、ターミナルから呼んだり、自動処理に組み込んだり、外部のシステムから呼び出して結果だけ受け取ったりする使い方が並んで存在していて、それぞれ料金の出口・人間の確認が入る場所・触れるファイルの範囲が変わります。
本記事は、AI への入口 (どこから AI に話しかけるか) を 7 区分に分けて整理し、それぞれが「手で使う AI」なのか「自動で動く AI」なのかを地図化するための解説です。今回は AI モデルの違い (GPT と Claude のどちらが賢いか) の話ではなく、また個別の機能 (拡張機能・MCP・カスタム指示) の話でもなく、「AI をどこから呼び出すか」という通信層の話だけに絞ります。
普段の使い方が Chat 画面 1 種類だけの方は、まずその使い方が 7 区分のうちどこに当てはまるかを把握すれば十分です。複数の入口を同時に使い始めている方や、これから自動化に踏み込もうとしている方は、入口ごとに料金の出口と権限管理が別物になるため、自動化を組む前に呼び出し口の地図を握っておくと、後から「サブスクとは別の請求がいつの間にか発生していた」という事故を避けられます。
最初に確認しておくべきことは 2 点だけです。1 点目は、ChatGPT Plus や Claude Pro / Claude Max のような月額契約 (以下「サブスク」) と、OpenAI / Anthropic の API 利用料は別物の請求で、ログイン画面も別の URL (chatgpt.com / claude.ai と platform.openai.com / console.anthropic.com / platform.claude.com) を使い分けるという事実。2 点目は、commands / skills / rules / instructions といった「AI への指示ファイル」と、「AI をどこから呼び出すか」は別レイヤーで、指示ファイルを置いただけでは呼び出し口は変わらないという事実です。この 2 つを冒頭で握っておくと、本記事の地図がそのまま頭に入ります。
なお、本記事の前段として、料金モデルの 3 種類 (サブスク / API / ローカル LLM) を整理した ChatGPT月額・APIとローカルLLM、何が違うのか：AIの使い方は3種類ある を読んでおくと、本記事の「呼び出し口 7 区分」を料金軸と重ねて理解できます。読まなくても本記事だけで完結する構成にしていますが、前提を強めたい場合は前段として参照してください。
AIの呼び出し方を分けないと自動化で詰まる理由
自分が AI を Chat 画面でだけ使っているのか、CLI から呼び出しているのか、自動処理に渡しているのかが区別できていないと、料金がどこから別扱いになるか、どこから人間の確認が消えるか、どこから危険性が増えるかを判断できなくなります。本記事は、Chat・Claude Code・claude -p・GitHub Actions・Agent SDK・API キー直叩きという「AI をどこから呼び出すか」の通信層を、手動 / 自動と対話 / 非対話の 2 軸で並べ直すための地図です。普段の Chat 画面利用は手動・対話の入口、ターミナルで claude を起動するのは同じ手動・対話でも開発環境側の入口、API キーをスクリプトに渡す時点で自動・非対話の入口に切り替わる、というように呼び出し口で性格が変わります。最初に確認しておくべきはサブスクの登録画面 (chatgpt.com / claude.ai) と API の管理画面 (platform.openai.com / console.anthropic.com / platform.claude.com) が別物である、という事実です。
Chatで使うAIと裏側から呼び出すAIの違い
ブラウザの Chat 画面で人間が 1 問 1 答する利用と、ターミナルやスクリプトから呼び出して結果だけ受け取る利用では、人間の確認が入る位置と料金の出口が変わります。同じ「AI を使う」でも、見ている画面・触っているファイル・支払い先が別物です。
Chat 画面の利用は「人間が画面に張り付き、毎回出力を読んでから次の指示を出す」運用が前提になります。出力を読まずに次へ進める余地は基本的になく、ファイル操作も画面内に閉じます。一方、ターミナルやスクリプトから呼び出す利用では、結果を読まずに次の処理へ渡したり、人間が席を外している間に処理を進めたりできます。確認のタイミングが自動的には来ないため、自動化に踏み込む前にどこで止めるかを設計する必要があります。
この違いは、AI 時代に作業者のままで残ることのリスクと裏返しで、判断を AI 側に渡したい人ほど Chat 画面の外へ出ます。シリーズ入口記事として AIで今後自分の仕事はどうなる？｜AI時代に作業者のままでは危ない理由 を関連記事として置いておきます。
AIを使う入口が変わると責任と料金も変わる
ChatGPT Plus や Claude Pro / Max の月額契約は、それぞれ chatgpt.com と claude.ai の利用権で、OpenAI API や Anthropic API の利用料は両社公式ヘルプ (help.openai.com/en/articles/6950777 / support.claude.com/en/articles/9876003) で別請求と明記されています。サブスクと API のどちらの財布から引かれるかは、呼び出し口で決まります。
ブラウザでサブスクにログインして使っている範囲では、API 課金は発生しません。逆に、ターミナルで API キー (ANTHROPIC_API_KEY / OPENAI_API_KEY) を環境変数に入れて呼び出した時点で、サブスクとは別の請求枠 (API 従量課金) から引かれます。同じ「Claude を使った」「ChatGPT を使った」でも、呼び出し口が変わると財布が切り替わる構造です。
責任の所在も同様で、Chat 画面では出力に対する判断は人間が画面で行うのが前提ですが、API キー経由で自動処理に渡した結果は、人間が見ないまま次のシステムに連携される構造になります。料金と責任は、呼び出し口の選定とセットで決まります。
自動化前に整理すべき呼び出し口
自動処理を組む前に、自分が今どの呼び出し口を使っているかを「ブラウザ Chat / Claude Code 対話 / claude -p / GitHub Actions / Agent SDK / API キー直叩き」のどれに該当するか 1 行ずつ書き出すと、後から課金枠と権限管理を当てはめやすくなります。複数の呼び出し口を同時に使っているケースが大半です。
実務では、たとえば「日中の調査は ChatGPT Plus の Chat 画面 / コード編集は Claude Code 対話 / 定期処理は将来 claude -p か API キー経由」のように、用途と呼び出し口が枝分かれします。書き出しの単位は「使う場面 × 呼び出し口 × 料金の出口 × 触れるファイル範囲」の 4 列が目安です。
この棚卸しを先にやっておくと、後続の各 H2 で扱う Chat / Claude Code / claude -p / GitHub Actions / Agent SDK / API キーの説明を、自分の使い方にそのまま当てはめながら読めます。本記事の地図と自分の現状を 1 対 1 で照合できる状態を作ってから先に進んでください。
ChatとClaude Codeの違い
Chat (chatgpt.com / claude.ai) はブラウザに月額契約でログインして対話する入口、Claude Code は端末上で claude コマンドを起動して開発環境を触らせる入口です。同じ「AI に話す」行為でも、画面・認証・触れるファイルの範囲が違います。
Chatは人間が画面で対話する入口
Chat はメール+パスワード認証でブラウザにログインし、サブスク月額の枠内で利用するユーザーアカウント単位の使い方です。ファイル操作はアップロード / ダウンロード以外発生せず、端末上のファイルを直接編集することはありません。
利用の単位は「個人のサブスク契約」で、組織管理ではなく個人アカウントが基準になります。1 回 1 回の入力に対して 1 回の出力が返り、人間が画面で読んでから次の入力を投げる、という対話ループが前提です。利用量の上限はサブスクのプラン (Plus / Pro / Team / Enterprise 等) によって異なりますが、いずれも従量課金ではなく月額固定の上限内で使う構造になります。
ブラウザ Chat は「AI を初めて使う人が最初に触る入口」として最も広く使われており、本記事の 7 区分の中では最も人間ゲートが多い使い方です。出力をそのまま採用せず、画面で読んで判断するプロセスが構造的に組み込まれています。
Claude Codeは開発環境で作業を進める入口
Claude Code は claude を起動して Claude.ai OAuth または ANTHROPIC_API_KEY で認証し、開発環境のファイルやコマンドを実行する入口です。Claude Code 公式ドキュメント (code.claude.com/docs/en/authentication) に従い、ANTHROPIC_API_KEY が環境変数にあると OAuth より優先され、課金経路がサブスクから API 従量に切り替わります。
起動コマンドは以下のように、ターミナルから claude を打つだけです。
claude
OAuth で claude.ai 側に紐づけた場合は Claude Pro / Max のサブスク枠を消費し、ANTHROPIC_API_KEY を環境変数に入れた場合は Anthropic API の従量課金枠を消費します。同じ claude コマンドでも、認証経路の選び方で料金の出口が切り替わる構造です。
export ANTHROPIC_API_KEY=...
Claude Code は、ファイル編集・コマンド実行・ディレクトリ走査などの操作を AI 側から提案させ、人間が承認すると実行に移ります。Chat 画面と比べて触れるファイルの範囲が広く、誤操作の影響範囲も広いため、起動するディレクトリを選ぶ段階から注意が必要です。
Chat感覚のままClaude Codeを使うと起きる混乱
Chat の「画面で 1 問 1 答」の感覚のまま Claude Code を使うと、ファイル編集やコマンド実行の確認をスキップしがちで、想定外の変更や課金経路の取り違えが起きます。ANTHROPIC_API_KEY の混入で意図せず API 課金になる事故は環境変数の管理漏れで発生します。
典型的な混乱は 2 種類あり、1 つ目は「画面で対話している感覚のまま Yes を押し続け、想定外のファイルが書き換わる」ケース、2 つ目は「サブスクで使っているつもりが、シェルの起動スクリプトに残った ANTHROPIC_API_KEY のせいで API 課金経路で動いていた」ケースです。どちらも、Chat 画面と Claude Code の前提が違うことを把握しないまま使い始めると起こります。
対処としては、Claude Code を使う前に「いま自分はサブスク OAuth で動いているのか、API キーで動いているのか」を起動時のログで確認する習慣を付け、自動化に踏み込む前に確認プロンプトを必ず読むことを徹底するだけでも事故が減ります。Chat と Claude Code は「同じ Claude」でも、画面・認証・触れる範囲・課金の出口がすべて違う、と先に握っておいてください。
claude -pと非対話実行の位置づけ
claude -p (または --print) は対話画面を見続けないで結果だけ返す「画面を見ずに自動で動かす使い方」の入口で、cron や n8n の shell ノードから呼び出すような自動処理に向きます。claude 対話と同じバイナリですが、人間の確認プロンプトが消える位置が違います。
claude -pは画面を見続けない実行方法
claude -p "<prompt>" で起動すると、結果だけ標準出力に返って終わるため、ターミナルに張り付かなくて済みます。サブスク OAuth でも動き、「claude -p には API キーが必要」は誤解で、2026-06-15 以降は Agent SDK クレジット枠 (自動実行用の毎月のクレジット枠) を消費する予定が公式に告知されています。
最も基本的な呼び出し方は以下です。
claude -p "<prompt>"
この 1 行で、対話画面を立ち上げずに 1 回だけ Claude に処理を投げて、結果を標準出力に返して終了します。シェルパイプ・cron・タスクスケジューラ・n8n の shell ノードなど、外部から定期的に呼び出す経路と相性がよく、人間が画面に張り付かない運用に振りやすい構造です。
なお、課金枠の話を扱う際には「自分の使い方が対象か」を先に判断できる材料を置いておきます。下記の表は、claude -p 周辺で今後どの経路がどの枠に紐づくか、自分がどれを使っているかを判断するための材料です。
| 使っている経路 | 普段の入口 | 今後の課金枠 (公式告知) |
|---|---|---|
Claude Code 対話 (claude) | ターミナル + OAuth | 従来どおりサブスク使用制限 |
claude -p・--print | ターミナル + OAuth or API キー | Agent SDK クレジット枠 (2026-06-15 以降) |
| Claude Code GitHub Actions | GitHub Secrets + API キー | Agent SDK クレジット枠 (2026-06-15 以降) |
| Claude Agent SDK | アプリ組み込み + API キー | Agent SDK クレジット枠 (2026-06-15 以降) |
公式の数値・条件・期日の詳細はここでは扱いません。本記事の主題は呼び出し口の地図づくりであり、claude -p についてはまず「対話画面を見ずに 1 回だけ呼び出す経路」という位置づけだけ握ってください。クレジット枠の試算・換算は別記事の対象とします。
非対話実行で人間の確認が消える範囲
「画面を見ずに自動で動かす使い方」では確認プロンプトを出さずに進む選択肢を取りやすく、--bare モードは OAuth / keychain をスキップして ANTHROPIC_API_KEY 必須になります。--dangerously-skip-permissions を併用してもルートディレクトリ削除には依然プロンプトが残り、コンテナ / VM 隔離環境前提の使い方です。
claude -p --bare
--bare モードで起動すると、ローカル keychain の OAuth トークンを参照しないため、別の経路で ANTHROPIC_API_KEY を渡す必要があります。CI / CD 環境やコンテナ内で動かすときに使う構成で、人間が席にいない前提の経路です。確認プロンプトをすべて消すわけではない点に注意が必要で、危険度の高い操作には個別のプロンプトが残ります。
非対話実行に踏み込む段階で重要なのは、「人間ゲートがいつ・どこで消えるか」を構成ごとに書き出しておくことです。claude -p だけなのか、--bare 付きなのか、--dangerously-skip-permissions まで付けるのか、で消えるゲートの位置が変わります。これらの組み合わせ条件は本記事のスコープ外ですが、選定基準は「人間が席にいなくても、誰のどの判断が止め役になるか」で 1 段ずつ決めると整理しやすくなります。
コマンド化する前に固定すべき入力と出力
非対話実行をスクリプトに固定する前に、入力プロンプト・期待する出力形式・失敗時の扱いを書き出しておかないと、後から呼び出し回数だけが増えて止め方が分からなくなります。コマンド化の単位はあらかじめ書面で確定させておく価値があります。
実務での目安としては以下の 4 項目を、コマンド化前に紙またはドキュメントで固定しておきます。
- 入力プロンプトの定型 (どんなテキスト / ファイルを渡すか)
- 期待する出力形式 (自由文 / 箇条書き / JSON / 特定タグの中身など)
- 失敗時の扱い (再実行するか / 通知するか / 無視するか)
- 終了条件 (1 回で終わるか / ループするか / 上限回数があるか)
この 4 項目を曖昧なままコマンド化すると、後で「呼び出し回数だけ増えて、何のために動いているか分からないジョブ」が残ります。claude -p はそれ自体は便利な経路ですが、書面化を怠ると自動化のメンテナンスコストが膨らむため、コマンド化前の固定作業を省かないでください。
GitHub ActionsでAIを呼び出す意味
GitHub Actions は push やプルリクエストなどのイベントを契機に AI 処理を自動起動する入口で、GitHub Secrets に ANTHROPIC_API_KEY を入れる構成が標準です。Claude Code 公式ドキュメント (code.claude.com/docs/en/github-actions) は「Each Claude interaction consumes API tokens」と明記し、サブスクからは引かれません。
GitHub Actionsはイベントで処理を起動する入口
手で起動するのではなく、push / pull_request / schedule / workflow_dispatch などのイベントをトリガーにジョブを走らせる仕組みです。AI 呼び出しもこのイベントの上に乗せる構成で、人間がトリガーするのは最初の 1 回だけになります。
イベントトリガーは複数を同時に設定できるため、たとえば「push 時にコード変更を要約させる」「PR 時にレビューさせる」「毎朝 9 時にスケジュール起動して進捗をまとめる」のような構成を 1 つのリポジトリで並列に持てます。AI への呼び出しはどのトリガーから来ているかでコンテキストが変わるため、ジョブ名・コメント・出力の宛先 (PR コメント / コミット / 別ファイル) を設計時に決めておく必要があります。
GitHub Actions を入口にする時点で、人間が席にいない時間帯でも AI が動く構造になります。Chat 画面の「読んでから次へ」の前提は完全に外れ、AI の出力は自動的に次の処理 (コメント追加・ファイル更新・Slack 通知など) に渡る構成になります。
自動実行では人間の操作待ちが減る
確認プロンプトが画面に出ても誰も応答しないため、自動実行用に確認をスキップする設計にするか、確認が必要な処理は Actions 側に乗せない判断が必要になります。操作待ちが減ることは、人間ゲートが消えることと裏返しです。
ジョブが走り始めると、AI の出力が想定外でも、止める仕組みを別途仕込まない限り処理は進みます。AI から見ると、Chat 画面では「人間が読んでから次」だった構造が、Actions では「AI が出力したらそのまま次のステップへ」になります。出力の妥当性は人間が事後に PR コメントや commit log を読んで確認する形になり、確認のタイミングは AI 実行中ではなく実行後にずれます。
ここを設計せずに自動化を始めると、「気付いたら大量のコメントが PR に追加されていた」「想定外のファイルがコミットされていた」という事態になります。Actions に AI を載せる時点で、確認の位置を「実行中」から「実行後」に明示的にずらす設計が必要、と認識しておいてください。
自動実行に入れる前に分けるべき権限と失敗時の扱い
GitHub Secrets に渡す API キーの権限範囲、Workspace 単位の利用量、ジョブ失敗時の通知経路をあらかじめ分けておかないと、サブスクとは別の請求が静かに増える構造になります。OpenAI の spend limit は soft cap で、超過後もリクエストは止まりません。
GitHub Secrets 経由で ANTHROPIC_API_KEY を入れる場合、そのキーは GitHub のリポジトリレベル (またはオーガニゼーションレベル) で管理されます。Workspace 単位の利用量上限・通知設定・スパイク検知などは AI 提供側 (Anthropic / OpenAI) のコンソールで別に設定する必要があり、GitHub 側と AI 提供側の両面で監視を持つ構造になります。
ジョブ失敗時の扱いも分けておく必要があり、「失敗を Slack / メールに通知する」「リトライを禁止する」「特定の失敗パターンでジョブをキャンセルする」など、人間ゲートを「実行前」から「失敗時のアラート」に置き直す設計になります。spend limit が soft cap である以上、課金の止まり位置は外側の監視層 (請求アラート・通知ジョブ・人間のチェック) に依存するため、AI 提供側の管理画面だけに頼らず、別の止め手を必ず用意してください。
Agent SDKとAPIキーの違い
Agent SDK (Claude Agent SDK / OpenAI Agents SDK) は「アプリや自動化ツールから AI を動かす仕組み」をアプリケーションやワークフローに組み込むためのライブラリ、API キーは AI を外部から呼び出すための認証情報です。SDK は道具、API キーは鍵で、同じ「自動化に使う」でも層が違います。
Agent SDKはAI処理を組み込むための道具
pip install claude-agent-sdk や pip install openai-agents でインストールするライブラリで、自前アプリやワークフローにエージェント処理を組み込むときに使います。Claude Agent SDK は 2026-06-15 以降、claude -p や Claude Code GitHub Actions と同じ月次クレジット枠を消費する予定が公式に告知されています。
pip install claude-agent-sdk
pip install openai-agents
SDK は「自分のアプリケーションコードの中で AI を呼び出す」ための道具で、関数呼び出し・ツール呼び出し・会話履歴管理・エラーハンドリングなどをライブラリ側が面倒見てくれる構造になっています。SDK を使わずに API を直接叩くこともできますが、その場合は HTTP リクエストの組み立て・認証ヘッダ・JSON のパース・リトライ処理を自分で書くことになります。
SDK が「自動化に使うための便利な道具箱」だとすると、その道具箱を使うために必要な認証情報が API キーです。SDK 自体は道具で、鍵 (API キー) なしでは動きません。
APIキーはAIを外部から呼び出すための鍵
API キー (ANTHROPIC_API_KEY / OPENAI_API_KEY) は AI への呼び出しを認証する文字列で、SDK を使う場合も HTTP を直叩きする場合も同じ鍵が必要になります。OpenAI Agents SDK 公式サンプル (openai.github.io) は export OPENAI_API_KEY=sk-... を要求し、ChatGPT Plus 契約とは独立です。
export OPENAI_API_KEY=...
API キーは「自分が AI 提供側に発行してもらった呼び出し権」で、サブスク契約とは別物です。ChatGPT Plus に加入していても、それは chatgpt.com 上での Chat 利用権であり、OpenAI API の利用権ではありません。API を使うには platform.openai.com で API キーを発行し、API 利用料の支払い手段を別に登録する必要があります。Anthropic も同様で、Claude Pro / Max は claude.ai 上での利用権、API 利用は console.anthropic.com / platform.claude.com で別途キーを発行します。
鍵は文字列なので、漏洩したら誰でも使えます。コミットしてはいけない、Slack に貼ってはいけない、.env を Git に上げてはいけない、というセキュリティ運用が必要で、漏洩した瞬間に課金の流出経路になります。
APIキーを使う時点で料金と管理の見方が変わる
API キーで呼び出した時点で、料金はサブスクではなく API 従量課金、漏洩リスクは鍵の流出範囲、利用量管理は Anthropic Workspace / OpenAI Organization・Project の階層単位、と見るレイヤーが変わります。複数人で 1 つの API キーを使うとレートリミットを食い合い、Anthropic のキーは Workspace をまたいで移動できません。
利用量管理は「個人のサブスク契約」から「組織 / プロジェクト単位の従量課金」に切り替わります。Anthropic は Organization の下に Workspace、その下にメンバー / API キーが並ぶ構造、OpenAI は Organization の下に Project、その下にメンバー / API キーが並ぶ構造で、利用量の集計・上限設定・課金分離もこの単位で行います。
複数人のチームで 1 本の API キーを共有すると、レートリミット (1 分あたりのリクエスト数 / トークン数) を全員で食い合うため、誰かのジョブが詰まると他の人のジョブも詰まります。最初から個別のキーを発行するか、Project / Workspace を分けて管理するのが定石です。API キーの取り回しは、サブスクの「個人 ID + パスワード」とは別の運用設計が必要、と頭を切り替えてください。
AIの呼び出し方と指示ファイルの違い
commands / skills / rules / instructions は「呼び出した後に AI をどう動かすか」の指示層であって、「どこから AI を呼び出すか」の通信層ではありません。指示ファイルを置いても呼び出し口は変わらず、自動化を組むなら呼び出し口の選定が別途必要です。
commandsは呼び出した後の定型操作
/blog-plan のような commands は、AI を呼び出した後に決まった手順を走らせるための定型操作の単位で、Chat でも対話 Claude Code でも claude -p でも、呼び出し口を変えても同じ commands を使えます。
commands は「AI に対するスクリプト的な指示」で、呼び出し口がブラウザの Chat であってもターミナルの Claude Code であっても、AI 側に同じ手順を踏ませる構造になっています。呼び出し口を切り替えても commands の中身は変わらないため、commands の整備は通信層の選定とは独立に進められます。
逆に、commands を整備しただけでは「ターミナルから自動で呼ばれる」ようにはなりません。自動化したい場合は、呼び出し口側 (claude -p / GitHub Actions / Agent SDK / API キー) を別途選定する必要があります。
skillsは作業手順を渡す仕組み
skills は Anthropic 策定のオープンスタンダードで、SKILL.md + scripts/ + references/ + assets/ の構造で作業手順を AI に渡す仕組みです。呼び出し口を変えても skills 自体は同じ場所から読まれ、呼び出し口を切り替える機能はありません。
skills は「AI に渡す作業マニュアルとその付属物」をディレクトリ単位でまとめた仕組みで、ファイルとして保存されているため、ブラウザ Chat (対応した拡張があるケース) でも、Claude Code でも、Agent SDK 経由でも、同じファイルセットを参照できます。呼び出し口の選定とは別レイヤーで、「どの作業手順を AI に渡すか」を整理する層になります。
skills を充実させても、呼び出し口を Chat 1 つに固定したままであれば、自動化は進みません。自動化したいかどうかは呼び出し口の選定で決まり、skills はその両方で共通して使える資産という位置づけです。
rulesとinstructionsは守らせる制約
rules と instructions は AI に守らせる制約や前提を書く層で、Claude Code の rules / CLAUDE.md / OpenAI Agents SDK の instructions= のように製品ごとに名前が違いますが、いずれも「呼び出し口」を変える仕組みではありません。Claude Code 公式 (code.claude.com) は「Permission rules are enforced by Claude Code, not by the model」と明記しています。
制約層は「AI にこういう操作はさせない」「この前提を必ず守る」といったガードレールの役割で、呼び出し口がどこであっても、制約を効かせたい範囲に書いておくと有効になります。Claude Code 側の rules は Claude Code が実行時に強制する仕組みで、モデル側の判断には依存しません。OpenAI Agents SDK の instructions= は SDK 側のセッション設計で渡す前提テキストで、これも呼び出し口とは別レイヤーです。
ここで言いたいのは、「AI を業務に組み込みたいなら、まず呼び出し口の選定、次に指示層の整備」という順序です。指示層を先に作っても、呼び出し口がブラウザ Chat だけなら自動化は始まらず、呼び出し口を切り替えてから指示層を整える、という順番でないと「ツールは揃っているのに動かない」状態になります。判断と作業の分離の観点では、シリーズ並列記事の AIをどう活用するか──手放す作業と残す判断、作業者に戻らない使い方 が、作業と判断の分離側からの整理を扱っているため関連記事として置きます。
まとめ
AI の呼び出し口は手動・対話の 2 区分 (Chat / Claude Code 対話) と自動・非対話の 5 区分 (claude -p / Claude Code GitHub Actions / Claude Agent SDK / OpenAI Agents SDK / API キー直叩き) に分かれ、サブスクと API は別請求で、Agent SDK と API キーは道具と鍵という別の役割を持ちます。指示層の commands / skills / rules / instructions は呼び出し口とは別レイヤーで、自動化を組むなら呼び出し口の選定が先になります。自分の業務に AI を組み込みたいが、サブスクと API のどちらが妥当か、どこから自動化に入るかを判断できない方は、お問い合わせください。
