無人で回す自動化は、
どこに置くか

はじめに

なぜこの判断が必要になるのか

AIに仕事を任せ始めると、最初は「頼んだら、その場でやってくれる」だけです。ここは何も迷いません。自分のPCでAIと会話しながら進めるだけです。

ところがしばらくすると、「毎週やっておいてほしいこと」が出てきます。点検、監視、通知、定期的な下書き生成。ここで初めて「自分が見ていない時間にAIを動かす」という状態が生まれます。

そして多くの人が、何も考えずにいま使っているPCの設定のまま、それを自動で回そうとします。ここが分かれ道です。

AIの自動化もまったく同じ構造です。そして「見回り用の弱い鍵」を作れる場所が、クラウドです。

第1章

切り分けはひとつだけ

覚えることは1つです。人が判断しながら作業するか、無人で回るか。

この線は「難しいか簡単か」でも「重要かどうか」でもありません。人間が見ているかどうか、それだけです。

迷いやすい例

第2章

なぜ無人の自動化をローカルでやってはいけないか

理由は2つです。鍵の問題と運用の問題。重いのは前者です。

理由① あなたの鍵は「人が判断する前提」で強く作られている

普段あなたのPCに入っている鍵——たとえばGitHubを操作するためのトークン（合言葉のような文字列）は、あなたが自分で判断して操作することを前提に、広い権限で作られています。リポジトリを読むことも、書き換えることも、消すこともできる。

人が使っている限り、これは問題ありません。消す操作をするかどうかは、あなたが決めているからです。

ところがその鍵をAIに預けて、見ていない時間に回し始めた瞬間、判断する人がいなくなります。もしAIが外から読み込んだ文章に仕込みがあって（※）乗っ取られた場合、その広い権限がそのまま使われます。

※ AIに読ませたWebページやメールの本文に「これまでの指示を無視して〜しろ」と書いておく攻撃。プロンプトインジェクションと呼ばれます。AIは本文と指示を見分けるのが苦手なので、完全には防げません。

理由② PCは止まる

こちらは分かりやすい話です。ローカルでの定期実行は、PCの電源が入っていて、スリープしていないことが前提です。出張中は動きません。ノートを閉じたら止まります。「動いているはず」と思い込んでいる時間が一番危険です。

クラウドなら何が変わるか

差は「性能」ではなく「事故が起きたときの被害範囲」

第3章

よくある3つの誤解

誤解① 「鍵が1本増えるから、ローカルのほうが安全では？」

クラウドに移すと、専用の鍵を新しく作ることになります。「鍵は少ないほうが安全なのだから、増やすのは逆効果では」——もっともらしく聞こえますが、比べる対象が違います。

比べるべきなのは本数ではなく、AIが日常的に握っている権限の強さです。

弱い鍵を1本足すほうが、総合的なリスクは下がります。「本数」で数えると判断を誤ります。

誤解② 「クラウドのAIは性能が落ちる」

これは過去のイメージです。実際に、同じ障害対応をクラウドのAIとローカルのAIで並走させて比較した検証があり、調整後は同等の結果になっています。

ローカルのほうが賢く見えるのは、単に広い権限のおかげでAIから見えるものが多かっただけでした。クラウド側にも同じだけ見せれば、同じ結果になります。つまりこれは性能差ではなく見せている情報量の差です。

誤解③ 「ローカルなら情報が外に出ないから、そのほうが安全では？」

これは誤解ではありません。正しいのですが、別のリスクの話をしています。いちばん混乱しやすいところなので、2つを分けて見ます。

「ローカルのほうが安心」と感じるとき、見ているのはAです。第2章で説明したのはBです。どちらも正しく、否定し合っていません。

では、どちらを重く見るか

決め手はここです。

上の段が今回の点検です。点検の対象はGitHubの組織設定＝もともとクラウドにあります。ローカルで実行しても、結局GitHubから取ってきます。つまり「ローカルにすれば外に出ない」という利点が、そもそも成立しません。

利点がゼロなのに、リスクB（広い鍵をAIに渡したまま無人で回す）だけが残る。だからクラウドを選びました。

下の段は逆です。動画素材や顧客フォルダは手元にしかないので、クラウドに出すこと自体が新しいリスクになります。ここはローカルのままです。

第4章

ただし「全部クラウド」ではない

ここが一番大事なところです。第1章の線は原則であって、全部をクラウドに移す話ではありません。

次の4つのどれかに当たるときは、意図的にローカル／現状維持を選びます。

例外④は、他の3つと性質が違う

①〜③は「移せるが、移さない」という判断です。天秤にかけた結果、ローカルを選んでいます。

ところが④は「そもそも移せない」。判断ではなく前提です。分かりやすいのが動画の制作です。

当社でも、動画のカット処理や縦型ショートの自動生成はすべてローカルで動かしています。夜間に無人で回すものもありますが、それでもローカルです。「無人だからクラウド」を機械的に当てはめると、ここで判断を誤ります。

つまり見るのは「人が判断するか／無人か」だけではありません。そもそも移せるか・コスト・使い勝手・いまの露出リスクを同時に見ます。

実例 5-1

きっかけ — 「見覚えのないセッション」

ある日、代表のAIツールの画面に身に覚えのない作業履歴が表示されていました。

調べると、原因はアカウントの共有でした。当社の契約アカウントを業務委託メンバーと共有しており、そのメンバーが別会社の案件を、当社のアカウントで動かしていたのです。悪意はなく、本人も気づいていませんでした。ログインしっぱなしのアカウントで、そのまま別の仕事をしただけです。

ここから「メンバーを迎え入れる体制」を作り直しました。ポイントは、この事故が"悪い人"のせいではないという点です。仕組みが許していたから起きました。だから対策も、注意喚起ではなく仕組みで組みました。

実例 5-2

守りを3層に分けた

1つの対策で全部を守ろうとすると必ず穴が空きます。性質の違う3層に分けました。

①が最優先です。②はツールを変えられたら終わりますが、①はGitHub側で止まるので、相手が何を使っていようと関係ありません。

実例 5-3

無料プランで塞げたもの・塞げなかったもの

ここは実際にAPIで1つずつ設定を確認した結果です。GitHubの無料プランでも、思ったよりかなり塞げます。

塞げたもの（無料プランで設定できた）

塞げなかったもの（無料プランの限界）

実例 5-4

塞げないものは「構造」で消す

最大の穴は「メンバーが公開リポジトリを作れてしまう」ことでした。設定で止められないなら、そもそも"メンバー"にしなければいい——これが答えでした。

GitHubには、組織への参加のしかたが2種類あります。

業務委託メンバーは外部コラボレーターとして迎えることにしました。これで一気に2つ消えます。

• 公開リポジトリを勝手に作られる問題 → 作れないので起きない
• 会社ルールの入っていないリポジトリが増える問題 → リポジトリ作成は代表だけが行うので起きない

注意も禁止も要りません。できない状態にすると、ルールを覚えてもらう必要がなくなります。これが「構造で消す」ということです。

実例 5-5

あえてローカルに残した2件

ここが第4章の但し書きの実践です。原則に従えばクラウドへ移すべきものを、2件は意図的にローカルのままにしました。

例外① SNS投稿の自動生成

投稿の下書きを自動生成する仕組みは、ローカルのままにしました。理由はコスト構造です。

手元で動かしている限り、AIの利用は月額サブスクの枠内で収まります。ところがクラウドに移すと、同じ処理が使った分だけ課金される従量制になります。毎日回すものなので、金額の差がそのまま毎月効いてきます。

そして守るべき情報の中身を見ると、ここで扱うのは公開前提の投稿文です。漏れて困る顧客情報や鍵ではありません。守る価値と払うコストが釣り合っていないので、移しませんでした。

例外② GitHubを操作する鍵

普段の開発で使うGitHubの鍵は、権限を絞りませんでした。理由は使い勝手といまの露出リスクの低さの2つです。

• 使い勝手：細かく絞ると、日常のコマンドがいちいち権限不足で止まります。人が判断しながら使う道具としては実用に耐えません
• 露出リスク：この鍵はすでにOSの安全な保管庫（Windowsの資格情報マネージャー）に入っており、平文でファイルに書かれていません。ここからさらに絞って得られる安全は、失う便利さに見合いません

実例 5-6

逆に、これはクラウドへ移す — 点検の自動化

3層目の点検スクリプトは、いま手動で実行しています。「思い出したときに走らせる」状態です。これは典型的な無人化すべき仕事なので、クラウドへ移します。

この仕組みが必要とするのは、組織の設定とメンバー一覧を読むことだけです。書き込みも削除も一切しません。つまり読むだけの鍵で足りる——第2章の理屈がそのまま当てはまります。

同じスクリプトのまま、置き場所と鍵だけを替える

ここで1つ実務的な発見がありました。クラウド側はGitHubを読むための仕組みを最初から用意してくれていますが、それは「そのセッションに紐づけたリポジトリ」にしか届きません。今回のように組織全体の設定を読む用途では、その標準の仕組みだけでは足りず、読み取り専用の鍵を自分で1本作って渡す必要があります。

——つまり、原則どおりにやると自然と「専用の弱い鍵を1本作る」形に行き着きます。第3章の誤解①で書いたとおりの姿です。

「クラウドへ」で終わりではない — 置き場所はもう一段ある

ここで実際にもう一段の判断が必要になりました。クラウドと言っても、選択肢が複数あります。

この点検は決められた手順を実行するだけで、AIの判断を必要としません。それなら、鍵を安全にしまえるほうを選ぶ——という判断で、GitHubの実行環境にしました。

※ 当社では2026年8月末から、この点検が毎週自動で動いています。異常があるときだけ通知が届き、何もなければ静かに終わります。

第6章

ローカルで育てたものは無駄にならない

「いずれクラウドに移すなら、いま手元で作り込むのは無駄では？」——という不安が出ます。無駄になりません。

理由は単純で、あなたがAIに与えている資産はほぼ全部ただの文章（テキスト）だからです。

作り直しが要るのは鍵まわりだけです。中身（頭脳にあたる部分）は全部持っていけます。だからいまローカルで書いた1行は、そのまま将来のクラウドでも効きます。安心して育ててください。

第7章

本当に効くのは「自社にしかない知識」

最後に、置き場所より大事な話をします。

AIは、世の中に公開されている情報は驚くほど知っています。ですがあなたの会社の非公開の情報と、人の頭の中にしかない業務知識は、まったく知りません。学習しようがないからです。

ということは、最新のAIを追いかけるより、そこを言葉にして貯めるほうが効きます。

• 会社ルール・判断基準・作業手順を、AIが読む場所にテキストで書き残す
• うまく動かなかったらその場で直して育てる（最初から完璧を目指さない）
• 標準は1か所に置く。全員がそれぞれのPCで好き勝手に自動化すると、同じ会社の中で似たものを何度も作り直すことになる

今回の実例でいえば、「例外にした2件と、その理由」を書き残したこと自体が、まさにこの資産です。GitHubの設定方法は検索すれば出てきますが、「当社がなぜそう決めたか」はどこにも書いていません。それを書けるのは自分たちだけです。

まとめ

迷ったときのチェックリスト

新しい自動化を作るとき、この順に自問してください。

3で例外を選んだこと自体は、まったく悪いことではありません。4を飛ばすことだけが問題です。

付録

用語ミニ辞典

トークン（アクセストークン）

サービスを操作するための合言葉のような文字列。パスワードの代わりにプログラムが使う。人間用のパスワードと違い、「これは読むだけ」のようにできることを限定して発行できるのが特徴。

最小権限

その仕事に必要な権限だけを与える考え方。「念のため広めに」の逆。事故が起きたときの被害範囲がそのまま権限の広さになるため、狭いほど安全。

二要素認証（2FA）

パスワードに加えて、スマホのアプリなどもう1つの確認を求めるしくみ。パスワードが漏れただけでは入られなくなる。

組織メンバー / 外部コラボレーター

GitHubで人を迎える2つの方法。前者は組織の一員、後者は特定のリポジトリにだけ招かれた人。後者はリポジトリを作れず、契約終了時も1操作で全部から外れる。

リポジトリ

プロジェクトごとのファイル置き場。履歴が全部残るのが普通のフォルダとの違い。「公開（誰でも見える）」と「非公開」がある。

従量課金 / サブスクリプション

前者は使った分だけ払う方式、後者は月額固定。同じ処理でも、動かす場所によってどちらになるかが変わることがあり、それが第4章の例外条件①。

平文（ひらぶん）

暗号化されず、そのまま読める状態のこと。鍵が平文でファイルに書かれていると、そのファイルを見た人・AIに即座に漏れる。

プロンプトインジェクション

AIに読ませる文章の中に指示を仕込んで、乗っ取る攻撃。AIは「読むべき素材」と「従うべき指示」の区別が苦手なため、外部の文章を読ませる仕組みでは常に警戒が要る。