📋 この記事でわかること
AIで作った社内ツールが動いている。成果も出ている。それでも社外の人には渡せない。この行き止まりの原因は、性能ではなく権限の設計です。この記事では、AIを窓口にした仕組みで権限の壁が見えなくなる構造、当社がこのコーポレートサイトをClaude Codeで運用するなかで手を入れた鍵の分け方、そして役割ごとの見える範囲を決める5つの手順を順番に整理します。読み終えたとき、御社は「誰に何を渡してよいか」を紙1枚で説明できる状態になります。いま動いているものを作り直す前提では書いていません。
📖 この記事は約16分で読めます。
「動いている」と「人に渡せる」の間には、一線がある
渡せない原因は、性能ではなく権限にある
生成AIに相談しながら、業務の仕組みを自分で組み上げる。専門職でなくても、これが現実にできるようになりました。当社もこのコーポレートサイトをClaude Codeで運用しています。日本語で指示を書くだけで記事ができ、ページが直り、サイトそのものも改修できます。
ところが、しばらく運用すると次の悩みが出てきます。動いているのに、ほかの人に渡せない。手伝ってほしい人がいる。別の部署にも広げたい。それでも渡せない。この行き止まりに、処理の速さや出力の精度はほとんど関係していません。誰が何を見てよいのかを、まだ決めていないから渡せないのです。
ここを性能の問題だと誤読すると、対処が全部ずれます。モデルを変えても、指示を練り直しても、渡せない状態は1ミリも動きません。動かすべきなのは仕組みの側です。
一人で作ったツールに、仕切りは存在しない
一人で作ったツールは、例外なく「自分が使う」前提で組まれています。自分は社内の情報を全部見てよい立場です。だから、わざわざ仕切りを作る動機がありません。売上のデータも、顧客の一覧も、外部サービスにつなぐための鍵も、同じ場所からたどれる状態で完成します。
これは手抜きではありません。一人で使っているあいだ、仕切りは1ミリの価値も生まず、作業を遅くするだけです。合理的に作れば、こうなります。ただしその合理性は「一人で使う」という条件の上にだけ成り立っています。そして条件は、御社が事業を伸ばそうとした瞬間に変わります。
二人目を入れた瞬間に、設計の欠落が表に出る
渡した相手は、作った本人とまったく同じ範囲に手が届きます。新入社員でも、業務委託の方でも、取引先の担当者でも同じです。アカウントを渡す行為が、そのまま全権を渡す行為になっている。これは運用の甘さではなく、設計上そうなっているという話です。
だから、勘の良い担当者ほど手が止まります。渡したい。でも渡した後に何が起きるか説明できない。説明できないものを渡す判断は、経営としてできません。結果、作った本人がツールを抱えたまま忙しくなり続けます。
そして、ここが見落とされがちな点です。本人しか触れない仕組みは、本人が休めない仕組みでもあります。属人化は事故のリスクであると同時に、いま現在の経営上の制約として効いています。
AIを窓口にすると、権限の壁は目に見えなくなる
従来のシステムには、見える壁があった
これまでの業務システムには、目に見える壁がありました。メニューが表示されない。ボタンが押せない。画面そのものが開かない。使う側も「ここから先は自分の担当ではない」と、操作しながら自然に理解できました。
設計する側にとっても、壁は作りやすいものでした。画面ごとに権限を割り当てればよく、割り当て漏れは画面を開いてみればすぐ分かります。権限設計の成否が、目で確認できたのです。
自然文の入口には、押せないボタンがない
AIを窓口にした仕組みには、その壁がありません。入口は、自然文で質問を書き込む欄ひとつです。そこには、押せないボタンも、開かない画面も存在しません。壁は作らない限り存在せず、作っていないという事実は、画面をどれだけ眺めても分かりません。
ここが従来のシステムとの決定的な違いです。従来は「権限を作り忘れたら画面に出る」。いまは「権限を作り忘れても画面は何も変わらない」。前者は運用しながら気づけますが、後者は事故が起きるまで気づけません。
モラルに頼った設計は、事故を予約している
手伝いに来た方が「今月の売上を教えてください」と尋ねる。業務上、ごく自然な質問です。しかし仕切りがなければ、その一言で経営数字にまで届きます。AIは、聞かれたことに答えるのが役割だからです。
これは相手を疑うかどうかの話ではありません。仕組みの側で線を引いていないなら、事故が起きるかどうかは相手の自制心次第になります。他人の自制心を前提にした設計は、事故を予約しているのと同じです。しかも予約の日付は、御社が人を増やした日、つまり事業が伸び始めた日に設定されます。
当社が自社サイトの運用でぶつかった、鍵の話
記事を1本足したいだけなのに、サイト全部を書き換えられた
当社はこのサイトを、日本語の指示だけで更新しています。記事を書き、ページを直し、サイトそのものも改修する。実例はWordPressとAIを活用した日本語指示によるホームページ更新のページに公開しています。
便利さは疑いようがありません。ただ、運用を続けるうちに一点、気になることが出てきました。作業に使っている接続情報が、必要以上に広い範囲まで届いていたのです。記事を1本追加したいだけなのに、その気になればサイト全体を書き換えられる。当社の場合、公開しているのは自社の情報だけなので、被害の想定範囲は限られます。それでも、この状態のまま人を増やす判断はできませんでした。実際、私は「この作業を誰かに任せたい」と思うたびに手が止まっていました。
用途で鍵を分ける──作業・公開・設定
そこで、用途ごとに接続情報を分けました。記事を書くための権限、公開状態を変えられる権限、サイトの設定に触れる権限。3つを別々にして、必要な人に必要なものだけを渡す形に整えました。
作業自体は地味です。新しい技術も要りません。難所は技術ではなく、「この作業には、どこまでの鍵が要るのか」を一つずつ言葉にするところにあります。
この棚卸しをすると、必ず気づくことがあります。日常業務の大半は、実はごく狭い権限で足りているという事実です。広い鍵を使い続けていた理由は、必要だったからではなく、分けていなかったからでした。
効果は、安全より先に「頼みやすさ」に出た
効果は、安全よりも先に別の形で現れました。頼みやすくなったのです。渡してよい範囲がはっきりしたので、任せる判断が速くなりました。「これは記事を書く鍵だけで足りる」と分かれば、迷う理由がなくなります。
権限を分ける作業は、守りの仕事に見えます。実際にやってみると逆でした。これは、広げるための作業です。仕切りがなければ、人を増やすたびに全権を配ることになります。仕切りを作った瞬間から、人を増やすことが単なる前進になります。
当社が内製AIツール診断で最初に見るのがこの部分なのは、ここが詰まっていると他の改善がすべて後回しになるからです。速度も精度も、渡せなければ事業の伸びには変換されません。
役割ごとの見える範囲を決める、5つの手順
手順1｜人からではなく、役割から書き出す
権限を考えるとき、つい「Aさんには何を見せるか」と人から入ります。これは必ず破綻します。人は入れ替わりますし、人ごとに決めると例外が増え続けるからです。半年後には、誰も全体像を説明できません。
先に役割を書き出してください。役割は多くても4つか5つで足ります。作った本人、日常的に使う人、内容を確認して承認する人、一時的に手伝う外部の方。人が増えたら、既存の役割のどれかに当てはめます。
| 役割 | 見てよい範囲の例 | 渡さないもの |
|---|---|---|
| 管理者（作った本人） | すべての操作と設定 | — |
| 日常利用者（社内） | 担当業務のデータ、作成と編集 | 設定変更、外部連携の鍵 |
| 承認者 | 内容の閲覧と公開の可否判断 | データの直接編集、設定変更 |
| 外部の協力者 | 依頼した作業の対象範囲のみ | 経営数字、顧客情報、鍵、履歴の全体 |
手順2｜役割ごとに、見てよい範囲を1行で書く
1行で書けない範囲は、まだ決まっていない範囲です。「必要に応じて」「基本的には」といった言葉が入ったら、そこは未決定だと判断してください。運用が始まった後、その曖昧さは必ず広い側に倒れます。人は迷ったとき、止めるより通すほうを選ぶからです。
書く単位は、機能名ではなく情報の種類にします。「レポート機能が使える」ではなく「今月分の受注データを見られる」。AIを窓口にした仕組みでは、機能ではなく情報が漏れます。機能単位で書いた権限表は、実態を映しません。
手順3｜鍵を用途別に分ける
外部サービスにつなぐための鍵を、用途ごとに分けます。1本の鍵を使い回している状態は、1本漏れたときに全部まとめて漏れる状態です。分けておけば、被害はその鍵の範囲で止まります。
あわせて、鍵の置き場所を決めてください。設定ファイル、指示文、チャットの履歴、共有フォルダ。鍵がどこにあり、誰が読めるかを即答できないなら、それは管理されていません。当社が診断で必ず確認するのもここです。
手順4｜止め方を、渡す前に決める
渡す手順は誰でも思いつきます。止める手順は、必要になるまで誰も考えません。そして必要になるのは、契約終了や退職といった、落ち着いて考える余裕がない場面です。
決めておくのは3つだけです。誰が止めるか。どの操作で止まるか。止めたことをどう確認するか。この3つを渡す前に書いておけば、その日に迷いません。止め方が決まっていない権限は、渡してはいけない権限です。
手順5｜誰がいつ何をしたかを残す
記録は、犯人を探すためのものではありません。何が起きたのかを、後から順番に追えるようにするためのものです。記録がなければ、止まった原因も、出力がおかしくなった時点も、特定する手段がありません。「再実行したら直った」で終わらせるしかなくなります。
| 決めること | 紙に書く内容 | 欠けていると起きること |
|---|---|---|
| 役割の一覧 | 誰がどの立場で触るのか | 例外が増え、全体を誰も把握できなくなる |
| 見てよい範囲 | 役割ごとに情報の種類で1行 | 触れる人が全員、経営数字まで到達する |
| 鍵の分離 | 用途別に接続情報を分け、置き場所を明記 | 1本漏れると、まとめて全部が漏れる |
| 止める手順 | 誰が、どの操作で、どう確認して止めるか | 退職や契約終了の後もアクセスが生き続ける |
| 記録 | 誰がいつ何をしたか | 原因を追えず、無関係な人の潔白も示せない |
この5つは、紙1枚に収まります。収まらないなら、役割を分けすぎです。説明に1枚を超える権限設計は、運用されずに形骸化します。
「うちは大丈夫」を支えている3つの前提
「信頼できる人しか入れないから大丈夫」
最も多く聞く言葉です。ただ、権限設計は人を疑うための道具ではありません。何かあったときに、その人を守るための道具です。
範囲が分かれていなければ、事故のときに「誰が触ったのか分からない」状態になります。それは、触っていない人の潔白も証明できないという意味です。信頼している相手だからこそ、疑われる余地を残さない。線を引く理由としては、これで十分です。
もうひとつ。信頼は人に紐づきますが、アカウントは組織に残ります。人が去っても、渡した権限は自動では消えません。信頼の話と、権限の話は、そもそも別の層にあります。
「小規模だから、そこまで要らない」
広げる予定がないなら、急ぐ必要はありません。判断の分かれ目は規模ではなく、変化の兆しです。外部の方に手伝ってもらいたい。別部署にも展開したい。顧客データを扱い始めた。このいずれかが視野に入った段階が、最も安く済むタイミングです。すでに渡した権限を後から絞る作業は、業務を止めながらの作業になります。
「危なくなったら、あとから直せばいい」
権限は、後から直すのが最も難しい部類の設計です。データの持ち方や処理の順番が、広い権限を前提に組まれているからです。仕切りを入れるには、その前提から作り直す必要が出てきます。
そして、直す動機が生まれる瞬間はたいてい事故の後です。事故の後は、情報がどこまで届いたかの特定、関係先へのご説明、再発防止の説明資料まで含めて、平時の何倍もの負担がかかります。直すコストが最も低いのは、まだ渡していない今日です。
30分で書ける権限メモから始める
そのまま使えるテンプレート
いきなり設計を変える必要はありません。まず紙1枚を書いてください。所要30分です。項目は5つだけです。
- 役割の一覧──いま触っている人を、4〜5の役割に分類する
- 見てよい範囲──役割ごとに、情報の種類で1行ずつ書く
- 鍵の一覧──外部サービスにつなぐ鍵を全部挙げ、置き場所を書く
- 止める手順──役割ごとに、誰がどう止めて、どう確認するか
- 記録──いま何が残っていて、何が残っていないか
書く相手は社内の誰かではなく、明日入る外部の協力者です。その人に渡す前提で書くと、曖昧なところが自分から浮き上がってきます。
詰まった行が、いま一番危ない場所
全部が埋まる会社は、まずありません。埋まらなくて構いません。重要なのは、どこで詰まったかを自分で把握することです。詰まった行が、いま御社で最も危ない場所です。
特に、鍵の置き場所と止める手順の2行で詰まるケースが目立ちます。この2つは、事故が起きたときの被害の大きさと、収束までの時間をそのまま決める項目です。
点検の観点をもう少し細かく確認したい場合は、内製AIツール診断のページに、権限以外も含めた10観点を一覧で掲載しています。専門用語をなるべく使わずに書いていますが、言葉の意味で引っかかった場合はIT業界用語辞典もあわせてご利用ください。
広げる前に、一度だけ外の目を入れる
「作れたのだから、直すのもAIに聞けばいい」。この発想は自然ですし、ある程度までは実際に進みます。ただ、権限設計だけは独力で越えにくい理由があります。AIは、聞かれたことにしか答えないからです。
権限の穴も、止め方の欠落も、こちらが「そこが危ないのでは」と疑って初めて論点になります。何が危ないかを知らない状態では、聞き方そのものが分かりません。だから、広げる直前に一度だけ外の目を入れる価値があります。
当社の初回ヒアリングは無料・オンライン・所要60分、全国対応です。動いている画面をひとつ見せていただければ、資料の準備は要りません。この60分で、最も危険度の高い箇所と、広げる前に決めておくことと、社内をどう説得するかの筋道をお持ち帰りいただけます。
権限を整えた先の話──内製したものを事業の資産として運用し続ける進め方は、Claude 法人導入支援にまとめています。
よくある質問（FAQ）
権限を分けると、作業が遅くなりませんか。
日常業務の大半は、狭い権限で足ります。当社が用途別に鍵を分けたときも、遅くなったという実感はありませんでした。速度に影響が出るのは、広い権限が本当に必要な作業だけです。その作業は数が限られます。
いま動いているものを、作り直すことになりますか。
多くの場合、そうはなりません。動いているという事実は大きな資産です。まずは今の構造を活かしたまま、危険度の高い箇所から順に手を入れます。作り直しをご提案するのは、そのほうが明確に安く早いと判断できる場合だけです。
外部の協力者に渡す場合、社内の人と考え方は変わりますか。
決める項目は同じです。違うのは、止める手順を先に決めておく重要度です。契約終了の日付が最初から見えている相手なので、渡す時点で止め方まで決めておけます。あわせて、依頼した作業の対象範囲だけに絞った権限を用意してください。
記録は、どこまで残せばよいですか。
起点は「誰がいつ何をしたか」の3つです。この3つが残っていれば、止まった原因の切り分けと、出力が変わった時点の特定ができます。全部を残そうとすると続かないので、まずは変更を伴う操作だけに絞って始めてください。
権限メモを書いたあと、次に手を付けるのはどこですか。
鍵の分離です。被害の範囲を最も大きく変える項目で、他の設計に手を入れずに着手できます。次が止める手順、その次が記録。見てよい範囲の実装は最後で構いません。順番を守るほど、業務を止めずに進められます。
相談するとき、何を用意すればよいですか。
動いている画面をひとつだけご用意ください。資料も事前の整理も不要です。画面共有で拝見しながら、業務のどこを自動化していて、誰が触っているかを伺います。一般論ではなく、御社の仕組みそのものについてお話しします。
✏️ 山崎 将史より
この回を書いたのは、当社への相談でいま最も多いのがこのテーマだからです。「AIで作ったツールが動いている。でも人に渡せない」。相談の入口はほぼ全部これで、しかも相談者ご本人は、原因が権限にあるとは思っていないことが多いのです。自分の作り方が悪いのではないか、と話し始める方もいます。そうではありません。一人で使う前提で合理的に作れば、誰がやってもああなります。
私はWebの構築を25年やってきて、道具が変わる場面を何度も見てきました。今回の変化がこれまでと違うのは、作れる人が一気に増えたのに、渡すための知識だけが置き去りになっている点です。以前は、作れる人がだいたい渡し方も知っていました。だから、動いているのに広げられないという状態が同時多発的に起きています。
当社は自社事業で、ハワイのコーヒーをクラウドファンディングから始めて、キッチンカーを経て実店舗、自社ECまで立ち上げました。そこで痛感したのは、おいしいものが作れることと、店として毎日出せることは、まったく別の能力だということです。味が良いだけでは、店は続きません。内製AIツールもこれと同じで、「自分だけで使う」から「チームや社外も使う」に移る瞬間に、必要な能力が入れ替わります。しかもその変化は、画面には何も現れません。
このコーポレートサイトをClaude Codeで運用しているのも、売るために始めたのではなく、自分たちが使うために始めたことです。使ってみて、権限で手が止まる感覚も、鍵を分けたら頼みやすくなる感覚も、両方こちらの体で確かめました。当社が「机上の空論を売らない」「自分の体で実証してから提供する」と言っているのは、そういう意味です。この記事に書いたことは、全部その場で口頭で説明できます。
もし、いま御社のツールを誰かに渡そうとして手が止まっているなら、止まっているのは正しい判断です。あとは、何を決めれば渡せるようになるかを言葉にするだけです。紙1枚、30分。書いてみて詰まったら、その場所を持って相談にお越しください。初回は無料・オンライン・所要60分、全国対応です。
