AIを安全に、
日常にする危

事故らない設定と、毎日の任せ方の話をします。
この資料では朱色を「危険・NG」の印として使います。

設定情報の確認日：2026年8月（AIツールの仕様は動きが速いので、日付のない資料は信じない）

まず見てください。

スライドはここで止めて、ここからはライブでやります。
2本とも、毎日の業務にある作業から選びました。

• エラーログ → 原因調査を2通り（貼って聞く／確認まで任せる）
• 雑な議事録 → 課題チケット

この2本は、あとで「任せ方の型」として全文を配ります。

ポイント：①は確認を自分の手でやる。②は確認まで任せて、報告の根拠を自分で検証する。この差が後半の「任せる線」につながります

ポイント：完成形（出力の形式）を先に指定する。コードを書かない業務でも同じ形で使える

便利かどうかの前に、
使っていいかを確認する。

設定画面は変わる。
見方は変わらない。

これから見せる各ツールの設定は2026年8月に確認した。UIは変わるので、この3点で自力で追えるようになるのが今日のゴールです。

個人アカウントは、
「学習オン」から始まる

コードを書く道具ほど、
コードを送っている

AIが「読む」だけでなく
「動く」ようになった

Claude CodeのようなエージェントはファイルもコマンドもWebも触れる。そこで生まれた攻撃がプロンプトインジェクション — 読ませた文書やWebページに仕込まれた指示で、エージェントが乗っ取られる。

3つ揃ったら攻撃可能、と覚える。対策：①自動承認で走らせるなら隔離した環境で — 本番の鍵と本番への接続は渡さない ②拡張・連携（MCP）は提供元を確認してから足す ③ログは全部読まなくていい。差分・外部通信・実行コマンドの3つを見る。

チャット画面の外にも、
送信経路がある

• ページ全体を読むブラウザ拡張は、開いてる社内画面ごと送っている可能性がある
• AIを内蔵したブラウザもある。有効にすると閲覧ページの内容がサーバに送られる（例：ChatGPT Atlas）
• 会議の自動文字起こし・要約は、自分が操作しなくても走る。発言は相手の管理下に残る
• 翻訳サイトも、入力データの扱いは同じ問題を持つ
• 「無料版だけ禁止」の会社が多い理由 ＝ データ取り扱い条件の差

見分け方はさっきの3点（学習・履歴・管理）と同じ。客先同席の会議では、文字起こしの扱いを先に確認する。

設定が完璧でも、
入れちゃダメなものはダメ。

実データは、
置き換えてから渡す。

聞きたいのは構造の話で、中身の値ではないことが多い。
置換してから聞けば、聞ける場面が増える。

適用範囲に注意：これはチャットに貼る場面の技術です。エディタやエージェントにリポジトリを直接読ませる場面では置換は効かない — そちらは「許可を取る」「読ませる範囲を絞る」で守る。社名を伏せても、構造から案件が分かることはある。

不明は、禁止として扱う。
そして、確認する。

聞くこと自体が「安全意識のある人」という評価になる。損しない。

今日はこの10個を見せる。
暗記は不要、全文を配ります。

太字＝今日ライブで見せる型（01・02は冒頭の実演）。* ＝ 客先の情報をほぼ入れずに使える型。制約が厳しい現場は、まずここから試す。

この10個は毎回手で打つものではなく、慣れたら指示ファイル（CLAUDE.md など）や定型コマンドに書いて固定するものです。もう毎日使っている人は固定まで進んでください。やり方は第3回で扱います。

技術メモを、
客先向けの報告文に直させる。

ポイント：「事実は変えない」を付けないと、表現と一緒に内容まで変わることがある。確認なしで送るのはNG

作る前に、
質問させる。

ポイント：着手前に曖昧な箇所が判明するので、手戻りが減る。先に計画を出して止まるモード（Claude Codeの計画モード等）を持つツールもある — 無いツール・聞いてこない場面で、この一言を足す

結論は聞かない。
材料だけもらう。

ポイント：条件を自分で列挙するほど比較の精度が上がる。採否の判断まで任せるのはNG

作業の名前ではなく、
確かめられるかで分ける。

同じ「要約」でも、元文書と突合できなければ任せてはいけない側に入る。作業名で覚えず、この2つの問い（確かめられるか・戻せるか）で毎回引き直す。

AIの出力は、
「優秀な新人の下書き」として扱う。

新人とひとつ違うのは、分からないときに黙らず断定してくること（上の例）。コードの間違いはLinterや実行がある程度拾ってくれる。ただしテストが緑＝正しい、ではない — AIがテストの方を要求に合わせて書き換えることがあるので、緑になった経緯は差分で確認する。道具が拾えないのは事実・仕様・文章の誤りで、これが断定調で返ってくる（ハルシネーション）。だから確認なしの納品は「任せてはいけない」側。確認して、直して、出す。「AIがやったから」は免責にならない。

質問はなんでも受ける。
相談は、その場で一緒に試す。

「現場のこの作業、AIでどうにかならない？」がある人は手を挙げてください。
いま一緒にやってみます。答えきれない分は次回の持ち込み枠に回します。

今日の内容だけでは、
開発はまだ速くならない。

今日やったのは「事故らない」と「手元の作業が楽になる」まで。個人が楽になっても、チームの速度はレビューと検証で決まる。しかも体感は当てにならない — 2025年の実測研究（METR）では、熟練開発者はAIを使うと実測で19%遅くなったのに、本人たちは20%速くなったと感じていた。

成果につなげる順番は、①計測する（かかった時間のメモはこのため）、②効いた型だけ残して固定する、③任せる範囲を広げる。この設計を第3回でやります。

METR RCT（2025-07・arXiv:2507.09089）：熟練OSS開発者16名・246タスクの無作為化比較。条件つきの結果だが、「体感と実測はズレる」ことの根拠になる。

宿題はありません。

やるかは自由です。次回は手ぶらでOK。困りごとを1個持ってくれば、持ち込み相談枠でその場で一緒にやります。試した人がいたら、聞かせてください。
次回：AIに「仕事の塊」を任せる回（エージェントの使い方と、客先で承認を取る話）。配布：設定チェックリスト（2026.08版）／NG・グレー・OK早見表／客先確認テンプレ／任せ方の型・全文集／任せる・任せないの判断表

無料で学べる公式教材、4つ。

この4つは、さらに先へ進みたい人向けです。URLは配布版のこのページから開けます。