AI実装のリアル山崎行政書士事務所のクラウド法務から見た、生々しい現場技術者の評価・考察

1. 結論

私は、AI実装を「便利な新機能の導入」とは見ていません。現場の感覚では、AI実装とは、業務システムの中に、判断し、推薦し、分類し、生成し、場合によっては実行まで行う新しい処理主体を入れることです。

だから、私が最初に見るのは、AIの性能ではありません。

誰のデータを読んでいるのか。どのデータを外部に送っているのか。どの権限で動いているのか。どのログが残るのか。誰が止められるのか。事故が起きたとき、誰が説明するのか。

この6点です。

AIは、EC、仮想試着、警備、研究、社内業務、コード生成、人事、SNS監視、AIエージェントまで、あらゆる業務に入ってきています。けれども、現場ではまだ「AIを使うこと」ばかりが語られ、「AIをどう止めるか」「AIが触ったデータをどう説明するか」「AIが間違えたとき誰が責任を取るか」が後回しにされています。

山崎行政書士事務所のクラウド法務として、私はそこを最も危ないと見ています。

2. 私がAI実装で最初に確認すること

AI導入の相談を受けたとき、私はまずデモ画面を見ません。最初に聞くのは、次のことです。

「このAIは、何を入力にしていますか」「その入力には、個人情報、秘密情報、顧客情報、社員情報、購買履歴、顔画像、体形情報、映像、ソースコードが含まれますか」「そのデータは、Azure上にありますか、外部SaaSにありますか、委託先が持っていますか」「AIの出力は、誰が確認しますか」「AIの出力は、そのまま顧客に出ますか」「AIは、読むだけですか、書き込みや注文や削除までしますか」「ログは、どこに何日残りますか」「そのログを、監査や事故時に出せますか」

現場では、ここを聞くと空気が変わります。

経営層は「AIで効率化できるか」を見ています。現場部門は「便利かどうか」を見ています。情シスは「動くかどうか」を見ています。法務は「規約に書けるか」を見ています。

しかし、事故が起きたときに問われるのは、全部まとめてです。

どのデータを使ったのか。なぜそのAIに渡したのか。誰が承認したのか。委託先は関与したのか。本人に説明していたのか。削除できるのか。ログは残っているのか。

AI実装は、ここまで設計して初めて実装です。画面にチャットボットを置いただけでは、実装ではありません。

3. 買い物支援AIの現場評価

買い物支援AIは、表向きは非常に分かりやすいです。商品を探す手間を減らす。口コミを要約する。似た商品を比較する。予算や用途に合う商品を提案する。

利用者にとっても便利です。EC事業者にとっても、クリック率や購入率の向上が期待できます。

しかし、私はここで必ず一歩引いて見ます。

買い物支援AIは、単なる検索窓ではありません。利用者が、検索では言わなかったことをAIに話し始めます。

「子どもの誕生日に失敗したくない」「父が病気なので使いやすいものがほしい」「体形を隠せる服を探している」「予算が厳しい」「妻に怒られない程度の価格で」「高齢の母でも使えるもの」「夜勤明けで疲れているので選んでほしい」

これは、ただの商品検索ではありません。家族構成、健康状態、経済状況、生活習慣、心理状態、嗜好が混ざります。

現場で本当に怖いのは、この対話データが「マーケティングデータ」として扱われることです。売上を伸ばしたい部門は、当然こう言います。

「この対話データを使えば、もっと精度の高いレコメンドができます」「広告にも使えます」「出店者にも渡したいです」「購入傾向分析に使えます」「AIの改善に使えます」

ここで止める人がいないと、AI導入は一気に危なくなります。

私が設計するなら、買い物支援AIでは、最低限、次を決めます。

AIとの対話内容を販売事業者に渡すのか。渡すなら、どの項目だけを渡すのか。家族構成、健康、予算、悩みのような情報を広告に使うのか。AIの提案理由を利用者に説明できるのか。AIが誤った商品を勧めた場合、問い合わせ窓口はどこか。購入代行をする場合、人間の最終確認を必須にするのか。注文、配送先、数量、サイズ、色、金額を最終画面で明示するのか。

特に、AIが購入ボタンまで押すようになると、リスクは別次元になります。AIが「おすすめ」するだけなら説明で済む場合があります。しかし、AIが「発注」するなら、それは業務実行です。

私は、買い物支援AIに決済権限を与えるなら、必ず人間の最終承認を入れるべきだと考えます。AIに任せる範囲と、人間が決める範囲を分けないと、誤発注、過剰購入、高額商品の購入、返品トラブルが起きたときに説明できません。

4. 仮想試着AIの現場評価

仮想試着AIは、事業としては非常に魅力があります。返品率を下げられる。購入率を上げられる。ECでも実店舗に近い体験を提供できる。利用者も、自分に合うサイズを選びやすくなる。

しかし、技術者として見ると、ここはかなり慎重に扱うべき領域です。

なぜなら、仮想試着AIは、体形情報を扱うからです。

身長。体重。肩幅。腕の長さ。胸まわり。腰まわり。足の長さ。顔写真。購入履歴。返品履歴。好みのブランド。よく着るサイズ。

これらが組み合わさると、単なる「サイズ情報」ではありません。かなり私的な身体情報です。

現場では、最初はこう言います。

「体形データはサイズ提案のためだけに使います」「顔写真は試着イメージのためだけです」「購入履歴と組み合わせると便利です」

しかし、しばらくすると別の要望が出ます。

「商品企画に使えませんか」「体形別に広告を出せませんか」「返品率の高い体形パターンを分析したいです」「顔写真を使って似合う商品を提案したいです」「他ブランドにも横展開したいです」

ここで目的が膨らみます。

私は、仮想試着AIでは、必ずデータを分けます。

サイズ提案に必要なデータ。顔合成に必要なデータ。購入履歴。返品履歴。マーケティングに使うデータ。AI改善に使うデータ。本人削除請求の対象データ。

これを分けずに、全部を「利便性向上のため」とまとめるのは危険です。

特に顔写真を扱う場合は、私は別扱いにします。顔写真は、利用者の心理的抵抗も大きく、漏えい時の被害も重いからです。

Azure上で設計するなら、体形情報や顔写真は、通常の購買履歴とは別の保管領域に置きます。アクセス権限も分けます。CS担当者が簡単に見られる状態にはしません。委託先が自由に閲覧できる状態にも しません。ログも残します。

ここで重要なのは、「暗号化しています」だけでは足りないということです。

誰が見たか。いつ見たか。なぜ見たか。どの委託先が触ったか。削除請求が来たとき、どこまで消せるか。

ここまで決める必要があります。

5. AI警備の現場評価

AI警備は、現場の人手不足を考えると、導入の必要性は高いです。転倒を早く検知できる。暴力や危険行為を早く見つけられる。警備員の監視負担を減らせる。ドローンやロボットと連携すれば、広い施設も少人数で見られる。

私は、この方向性そのものを否定しません。むしろ、適切に設計すれば、人命保護にもつながります。

ただし、AI警備で一番危ないのは、AIの検知そのものではありません。AIが「異常」と判定した後に、人間がどう動くかです。

現場では、こういうことが起きます。

AIが「転倒」と判定する。警備員が駆けつける。本当に急病なら助かる。しかし、ただ寝転んでいただけなら、本人は監視されたと感じる。

AIが「暴力」と判定する。警備員が制止する。しかし、介助やふざけ合いを誤判定している可能性がある。

AIが「不審者」と判定する。施設側が警察に映像を渡す。しかし、後から無関係な人だったと分かる。

ここで問題になるのは、AIの精度ではありません。運用基準です。

私は、AI警備では、最低限、次を文書化すべきだと考えます。

何を検知対象にするのか。AIの検知後、警備員は何を確認するのか。AIの判定だけで本人に声をかけるのか。警察への映像提供は誰が判断するのか。任意提供に応じる基準は何か。映像保存期間は何日か。AI学習に使うのか。本人から問い合わせが来た場合、どう説明するのか。誤検知が多い場合、誰がモデルや設定を見直すのか。

特に、警察や捜査機関への映像提供は生々しい論点です。

現場の施設管理者は、警察から「映像を見せてください」と言われると、断りづらいです。しかし、AIで高精度に解析された映像を広く渡すことは、プライバシー上の重い判断です。

私は、ここを「現場判断」にしてはいけないと思います。社内規程で、令状がある場合、緊急性がある場合、任意照会の場合、どのように判断するかを決めておくべきです。

AI警備は、便利な監視強化ではありません。人を守るための仕組みであると同時に、人を監視しすぎる危険もある仕組みです。

6. AIによる論文・研究支援の現場評価

AIが論文を作る。AIが仮説を出す。AIが実験計画を組む。AIが先行研究を要約する。

この流れは止まりません。

ただ、私は研究AIを「効率化ツール」としてだけ見るのは危険だと思っています。研究成果は、会社の知財、信用、競争力に関わります。誤った論文、存在しない引用、再現できない実験、盗用疑義が出れば、会社の信用を落とします。

現場では、こうなります。

AIが論文案を作る。担当者が少し直す。上司は「AIが作ったなら整っているだろう」と見る。投稿する。後から、引用が存在しない、実験条件が不明、データ処理が説明できないと問題になる。

ここで必要なのは、AI禁止ではありません。責任者の明確化です。

私は、研究AIでは、次を必ず決めます。

AIに未公開研究データを入力してよいか。AIが生成した文章をどこまで使ってよいか。引用チェックは誰が行うか。再現性確認は誰が行うか。AI利用の記録を残すか。論文、特許、技術資料でAI利用をどう扱うか。委託研究先がAIを使う場合、申告義務を課すか。

AIが論文を書けるかどうかより、AIが関与した成果物について、人間が責任を持って説明できるかが重要です。

7. 大企業の社内AI活用の現場評価

大企業でAI活用が始まると、最初は必ず明るい話になります。

削減時間。業務改善件数。社内公募。AI専門部隊。社長直轄組織。全社員向けAI研修。生成AIポータル。

どれも大事です。ただ、私はそこで安心しません。

大企業で本当に怖いのは、AI利用が見えなくなることです。

最初は公式AIだけを使っている。しかし、そのうち部門ごとのSaaSにAI機能が入る。チャットツールにもAIが入る。議事録ツールにもAIが入る。CRMにもAIが入る。開発ツールにもAIが入る。採用ツールにもAIが入る。委託先もAIを使い始める。

気づいたときには、誰がどのAIに何を入れているのか分からない。これが現場です。

私は、大企業のAI活用では、まずAI利用台帳を作ります。

部署。利用AI。利用目的。入力データ。出力の使い道。外部送信の有無。学習利用の有無。委託先関与。ログ保存。責任者。停止権限者。

ここで大事なのは、推進体制だけでなく、停止体制です。

AIが誤回答した。AIが個人情報を外部送信した。AIエージェントが誤操作した。AIが不適切な回答を顧客に出した。委託先が無断でAIを使った。

このとき、誰が止めるのか。誰が調査するのか。誰がログを見るのか。誰が顧客に説明するのか。

AI推進部門だけでは足りません。AI停止権限と事故対応フローが必要です。

8. コード生成AIの現場評価

コード生成AIは、現場ではすでに使われています。使わない方が不自然なほどです。

ただ、私は「コードの何割をAIが生成したか」という数字にはあまり興味がありません。重要なのは、AI生成コードが本番に入るまでに、誰が何を確認したかです。

AIは速いです。しかし、速いからこそ危ないです。

現場ではこうなります。

AIがコードを書く。開発者が動いたことだけ確認する。レビューが浅くなる。テストもAIが書く。人間が安心する。そのまま本番に入る。

後から見ると、認証処理が甘い。例外処理が雑。ログに個人情報が出ている。OSSライセンスが確認されていない。セキュリティヘッダーが抜けている。入力検証が不十分。権限チェックがない。

これは、AIが悪いというより、人間のレビュー設計が悪いのです。

私は、コード生成AIでは、次を必須にします。

AI生成コードのレビュー基準。セキュリティレビュー。OSSライセンスチェック。秘密情報の混入チェック。本番反映前の人間承認。AI利用ログ。委託開発でのAI利用申告。生成コードの責任分界。

特に委託開発では、契約にAI利用条項を入れるべきです。委託先が勝手にAIを使って、ソースコードや仕様書を外部AIに入力していた場合、発注者側の情報管理が崩れます。

コード生成AIは、開発効率化の道具であると同時に、委託契約・秘密保持・知財・脆弱性管理の論点です。

9. キャリア相談AIの現場評価

キャリア相談AIは、一見すると社員に優しい仕組みです。社員が自分のキャリアを考える。AIと壁打ちする。必要なスキルや異動先を考える。人材育成に役立つ。

しかし、私はこの領域をかなり慎重に見ます。

なぜなら、社員はAIに本音を入れるからです。

「今の部署がつらい」「上司とうまくいかない」「メンタルが限界かもしれない」「育児と両立できない」「病気があり、長時間勤務が難しい」「評価に納得できない」「転職した方がよいか」「昇進したいが何をすればよいか」

これは単なるキャリア相談ではありません。労務情報、人事情報、健康情報、家庭事情、評価への不満が混ざります。

ここで一番危ないのは、相談データを人事評価に使うことです。社員は壁打ちのつもりで入力した。会社は人材配置の参考にした。これが後から問題になります。

私は、キャリア相談AIでは、次を明確にすべきだと考えます。

相談内容を上司が見られるのか。人事部が個別内容を見られるのか。評価・昇進・異動に使うのか。匿名集計だけにするのか。保存期間は何日か。健康情報が入力された場合どう扱うか。ハラスメント相談が入力された場合、AIはどう案内するか。社員にどこまで説明するか。

社員向けAIは、顧客向けAIよりも説明が難しい場合があります。なぜなら、社員は会社との力関係の中で使うからです。

「任意です」と書いても、実質的に使わざるを得ない空気があるかもしれません。ここまで見なければ、クラウド法務としては不十分です。

10. SNS中傷検知AIの現場評価

SNS中傷検知AIは、被害を受ける人を守るために有効です。選手、著名人、社員、企業、ブランドを守るためには、AIによる検知は現実的な手段です。

ただし、私はここでもAI任せにはしません。

SNS投稿は、文脈が難しいです。隠語、皮肉、引用、冗談、方言、内輪ネタ、二次投稿があります。AIが「中傷」と判定しても、実際には批判や風刺かもしれません。逆に、AIが見逃した投稿が深刻な中傷かもしれません。

現場では、次が問題になります。

検知した投稿を誰が見るのか。被害者本人に見せるのか。精神的負担をどう減らすのか。証拠保全はどうするのか。削除依頼は誰が行うのか。発信者情報開示や法的対応は誰につなぐのか。誤判定された投稿への対応はどうするのか。

山崎行政書士事務所として関与するなら、紛争代理ではなく、事実整理と手順化が中心になります。

SNS投稿の保存手順。URL、日時、投稿内容、スクリーンショットの記録。AI判定後の人間レビュー。被害者本人への共有基準。弁護士連携フロー。警察相談やプラットフォーム申請のための事実整理。社内広報対応記録。

AIは検知補助です。法的評価や相手方対応をAIに任せてはいけません。

11. シャドーAIの現場評価

私は、シャドーAIが一番現実的で、一番危ないと思っています。

禁止しても、現場は使います。なぜなら便利だからです。

営業は提案書を早く作りたい。法務は契約書を要約したい。総務は議事録を作りたい。CSは問い合わせ回答を作りたい。開発者はコードを直したい。人事は評価コメントを整えたい。

そこで、個人アカウントのAIに入力します。

顧客名。取引条件。契約書。議事録。未公開資料。ソースコード。社員情報。クレーム内容。個人情報。

本人は悪気がありません。むしろ、会社のために効率化しているつもりです。

だから、私はシャドーAI対策を「禁止」だけで設計しません。禁止だけでは、隠れて使われます。

必要なのは、使える安全なAI環境を用意することです。そして、入力禁止データを明確にすることです。さらに、技術的に外部AIへの送信を可視化し、DLPで止めることです。

現場で必要なのは、次です。

承認済みAI一覧。利用禁止AI一覧。入力禁止データ一覧。社内AI環境。DLP設定。外部AI通信の監視。委託先のAI利用申告。違反時の是正手順。社員向けの具体例つき教育。

「個人情報を入れないでください」では足りません。現場は、何が個人情報で、何が秘密情報で、何が入力禁止かを具体的に知る必要があります。

12. AIエージェントの現場評価

AIエージェントは、チャットAIとは別物です。

チャットAIは、答えます。AIエージェントは、動きます。

ここが決定的に違います。

注文する。キャンセルする。返金する。メールを送る。チケットを起票する。コードを修正する。クラウド設定を変える。ファイルを削除する。顧客へ回答する。スケジュールを登録する。APIを叩く。

これは、AIに業務権限を与えることです。

現場で一番危ないのは、AIエージェントに共用アカウントや強いAPIキーを持たせることです。

「便利だから」と言って、AIに広い権限を与える。「PoCだから」と言って、ログを残さない。「後で直す」と言って、本番データに接続する。「人間が見るから大丈夫」と言って、自動送信を許す。

これが事故の入口です。

私は、AIエージェントでは、必ず権限表を作ります。

AIは何を読めるのか。何を書けるのか。何を削除できるのか。誰に送信できるのか。どのAPIを叩けるのか。金銭処理ができるのか。顧客対応ができるのか。人間承認が必要な操作はどれか。停止ボタンは誰が持つのか。ログはどこに残るのか。

AIエージェントは、新入社員ではありません。権限を持った自動処理主体です。

だから、IDも分ける。権限も最小にする。PIMや条件付きアクセスも考える。実行ログも残す。監査できるようにする。人間承認を入れる。

ここまでやらなければ、本番業務に入れてはいけません。

13. Azure技術者として見る実装ポイント

Azureを前提にすると、AI実装で私が見るレイヤーは決まっています。

まず、IDです。Entra IDで、従業員、外部委託先、顧客、AIエージェントのIDを分ける必要があります。共用アカウントは避けます。委託先アカウントは期限付きにします。管理者権限は常時付与せず、必要時昇格にします。

次に、データです。Purviewで分類します。個人情報、要配慮情報、秘密情報、顔画像、体形情報、社員相談情報、ソースコード、契約書を分類します。分類しなければ、AIに入れてよいデータかどうか判断できません。

次に、DLPです。外部AIに送ってはいけない情報を止めます。Teams、SharePoint、OneDrive、メール、端末、ブラウザ、SaaS連携を見ます。

次に、ログです。AI利用ログ、プロンプト、出力、API実行、モデル名、利用者、日時、承認者を設計します。ただし、ログを残しすぎると、ログ自体が個人情報の塊になります。だから、何を残すかだけでなく、何を残さないかも決めます。

次に、ネットワークです。AIがどこへ通信しているかを見ます。外部AI、社内AI、Azure OpenAI系の環境、SaaS、API、委託先環境を分けます。

次に、契約です。AIベンダーが入力データを学習に使うのか。ログを保存するのか。国外移転があるのか。再委託先がいるのか。削除できるのか。事故時に何時間以内に通知するのか。ここを見ます。

最後に、監査資料です。取締役会、監査、取引先、本人、行政に説明できる資料を作ります。技術構成図だけでは足りません。責任分界表、データフロー図、AI利用台帳、事故対応フローが必要です。

14. 私が作るべきだと考える成果物

AI実装企業に必要なのは、AI利用規程だけではありません。規程は必要ですが、規程だけでは現場は動きません。

私は、少なくとも次を作ります。

AI利用台帳

どの部署が、どのAIを、どの業務で、どのデータに使っているかを整理します。

AIデータフロー図

利用者、AI、Azure、外部SaaS、DB、ログ、委託先、広告、決済、CS基盤の流れを一枚にします。

AI入力禁止データ一覧

個人情報、秘密情報、契約書、ソースコード、顔画像、体形情報、社員相談、未公開資料などを具体的に書きます。

AIエージェント権限表

AIが読める、書ける、送れる、削除できる、注文できる、返金できる範囲を明確にします。

AIログ設計書

プロンプト、出力、利用者、モデル、日時、承認者、対象データをどこまで保存するか決めます。

AI委託契約・SOW条項

学習利用、保存期間、再委託、国外移転、監査、事故報告、削除、モデル変更通知を整理します。

AI事故対応フロー

誤発注、誤回答、情報漏えい、誤検知、差別的出力、AIエージェント暴走、委託先の無断AI利用に対応できるようにします。

経営層向けAI統制レポート

AI活用件数、未承認AI、入力禁止違反、重大リスク、是正状況、事故対応状況を経営会議で説明できる形にします。

15. 経営層への提言

経営層は、「AIで効率化しろ」と言う前に、次を決めるべきです。

AI事故が起きたとき、誰が説明するのか。AIが誤回答したとき、誰が責任を持つのか。AIが個人情報を外部送信したとき、誰が調査するのか。AIエージェントが誤操作したとき、誰が止めるのか。AIベンダーとの契約を誰が確認するのか。委託先がAIを使う場合、誰が許可するのか。AI利用状況を取締役会にどう報告するのか。

AI導入は、現場の努力だけで進めるものではありません。経営判断です。

数字を出すためにAIを入れる。その一方で、ログも契約も責任分界もない。これは、経営として危険です。

16. 情シス・法務・現場への提言

情シスは、AIを新しい管理対象として扱うべきです。アプリではなく、ID、権限、API、ログ、外部送信、DLP、監査の対象です。

法務は、AI規程だけで終わらせてはいけません。契約、委託先、学習利用、削除、再委託、国外移転、説明文書まで見なければなりません。

現場は、AIの便利さだけで突っ走ってはいけません。AIに入れてよいデータ、出してよい出力、任せてよい判断を理解する必要があります。

そして、これらをつなぐ人が必要です。

私は、山崎行政書士事務所のクラウド法務として、ここに価値があると考えています。

Azureの構成を読む。Entra IDの権限を読む。PurviewやDLPの設計を見る。Sentinelやログの証跡を見る。AI利用台帳を作る。契約条項に落とす。社内規程に落とす。責任分界表に落とす。監査説明資料に落とす。

AIを入れるだけなら、技術導入です。AIを説明できる状態にするのが、クラウド法務です。

17. 最終評価

AI実装の現場で本当に必要なのは、華やかな導入事例ではありません。必要なのは、泥臭い管理です。

AIが触るデータを把握する。AIが持つ権限を絞る。AIの出力を人間が確認する。AIのログを残す。AIのログを残しすぎない。AIベンダーとの契約を見る。委託先のAI利用を確認する。事故時に止める。本人や顧客に説明する。取締役会に報告する。

私は、AI実装を次のように定義します。

AI実装とは、AIを導入することではありません。AIが触れるデータ、AIが持つ権限、AIが出した判断、AIが残すログ、AIに関わる委託先を、Azure構成・契約・規程・監査資料で説明できる状態にすることです。

現場で必要なのは、きれいなスローガンではありません。AI利用台帳、データフロー図、権限表、ログ設計、委託契約、事故対応フロー、本人向け説明文書です。

なお、これは一般的な評価・考察であり、個別案件の法的判断、紛争対応、相手方との交渉、訴訟対応を目的とするものではありません。行政書士としては、契約、規程、責任分界表、事実証明資料、監査説明資料等の作成支援を中心にし、紛争性のある事案は弁護士等と連携する領域です。