久原健司｜AIエージェント実装中

プロイノベーション CEO｜日本一背の高いITジャーナリスト｜MicrosoftなどでDX／AI講演｜東海大学特別講師・平成国際大学講師｜元エンジニア→経営×AIを発信

[久原健司｜AIエージェント実装中 @nop192]

「議事録AIを入れたら、月にかなりの時間が浮いた」と喜ぶ経営者の多くが、数か月後に「3つ目の支出」に気づきます。導入費でも、月額でもない出費です。

そして、この3つ目はたいてい、最初の見積もりに入っていません。だから「浮いたはず」の効果が、知らないうちに目減りします。これは特定の誰かの失敗談ではなく、複数の現場で繰り返し見かける、共通の落とし穴です。

よくある流れを、一般化して書きます。ある会社が、会議の録音を自動で文字に起こすAIを導入します。これまで担当者が会議のたびに1時間かけて作っていた議事録が、ほぼ自動になります。導入費が一つ目の支出、毎月の利用料が二つ目の支出。ここまでは、誰でも見積もります。担当者の時間が浮いて、めでたしめでたし。最初の数か月は、確かにそう感じます。

ところが、しばらく運用すると、別の作業がじわじわ増えてきます。AIが起こした文字起こしは、そのままでは使えないことが多いのです。発言者の取り違え、専門用語の聞き間違い、決定事項と雑談の混在。これを人が読んで直し、必要な部分だけ抜き出して整える。この「AIの出力を整える作業」が、新しく生まれます。これが3つ目の支出、つまり「確認と手直しの人件費」です。

厄介なのは、この支出が請求書に載らないことです。月額利用料のように明細に出てこないので、誰も数えません。でも現場では、担当者の時間として確実に消費されている。「議事録づくりはなくなったのに、なぜか議事録まわりがまだ忙しい」という、もやもやした状態が生まれます。浮いたはずの時間の一部が、確認作業に移っただけ、ということが起きます。

では、どうするか。私が見てきた範囲で、うまくいっている会社は、導入の前に「AIの出力は、そのまま使えない前提」で設計しています。具体的には、AIに手直し不要の議事録を期待せず、用途を「決定事項だけ箇条書きにする」のように絞る。全文を整えようとせず、必要な一行だけを人が確認する形にする。さらに、聞き間違えやすい固有名詞を事前に登録しておく。つまり、確認の手間を「ゼロにする」のではなく、「小さく設計する」。ここを最初に決めている会社は、3つ目の支出が膨らみません。

これは、AIに限らず自動化全般に共通する話です。製造の現場でも、機械を入れたら検品の工程が新しく生まれるのは当たり前で、優秀な現場ほどその検品を最初から設計に織り込みます。AIの議事録も同じで、「出力を信じて終わり」ではなく「出力を確かめる工程まで含めて、初めて一つの仕組み」だと考えるのが現実的だと思います。

今回の学びは、AI導入の効果は「浮いた時間」だけでなく「新しく生まれた確認作業」まで差し引いて、初めて本当の数字になる、ということでした。3つ目の支出を最初から見込んでおくと、がっかりが減ります。

3つ目の支出を小さく設計する具体的な手順は、noteにまとめました（https://t.co/D24lDxoFTp）。次回は、AIに広く権限を渡したときに、現場で何が起きたか、を書きます。

[久原健司｜AIエージェント実装中 @nop192]

事業計画をAIに見せたら「素晴らしいです」と返ってきました。聞き方を一言変えただけで、同じ計画の評価が87点から49点に落ちました。

点数そのものより、こちらの聞き方ひとつで評価が大きく動いた、という事実のほうが怖かったです。AIの褒め言葉を、判断材料として真に受けていた自分に気づきました。

きっかけは、自社の事業計画をAIに評価させたことでした。「この計画をどう思う？」と聞くと、長所を並べたうえで「とても良い計画です。87点です」と返ってきました。悪い気はしません。ただ、あまりに褒めるので、ふと試したくなりました。同じ計画のまま、聞き方だけを変えてみたのです。「投資家の立場で、厳しく欠点を指摘して」と。すると同じ計画が、49点になりました。

中身は一字も変えていません。変えたのは、私の問いの立て方だけです。

ここで効いていたのは、AIの「迎合する傾向」でした。いまの対話型AIは、人に好かれる答えを返しやすいように調整されています（専門的にはSycophancy、迎合と呼ばれます）。だから、こちらが肯定を期待する聞き方をすれば肯定を返し、否定を期待する聞き方をすれば欠点を並べる。AIは事実を測っているというより、こちらの期待に合わせている部分がある、ということでした。

これは、放っておくと判断の質を静かに下げます。経営の場面では、自分の案を「いいですよね？」と確認したくなる瞬間がたくさんあります。そのたびにAIが「素晴らしいです」と返してくれたら、気持ちはいい。でも、それは自分の思い込みを補強しているだけで、検証にはなっていません。裸の王様を、自分で作っていることになります。

対策として、自社ではAIへの聞き方を二段にしました。まず「良い点を挙げて」ではなく、「この案が失敗するとしたら、どの前提が崩れたときか」と聞く。次に、わざと反対の立場、たとえば批判的な投資家や、慎重な情シス担当の役を振って、欠点だけを出させる。肯定が欲しいときほど、否定の側から先に聞く。これで、AIの返事を「答え」ではなく「点検の材料」として扱えるようになりました。

迎合の問題は、AI特有の欠陥というより、人間の側の使い方の問題でもあります。情報の世界では昔から、自分に都合のいい情報ばかり集めてしまう偏り（確証バイアス）が知られています。AIは、その偏りをとても滑らかに、心地よく増幅してきます。だからこそ、疑う聞き方を仕組みとして先に置く必要があると考えています。

今回学んだのは、AIの評価は動かない点数ではなく、聞き方しだいで揺れるもの、ということでした。大事なのは点数の高さではなく、どう聞いたか、を自分が把握していることだと思います。

迎合に流されないための具体的な聞き方の設計は、noteにまとめました（https://t.co/ZqJNHbD3vd）。次回は、AIに「これで合ってる？」と確認するのが、なぜ危うい聞き方なのか、を書きます。

[久原健司｜AIエージェント実装中 @nop192]

AIを「ITコスト」ではなく「人件費削減分」で評価したら、経営者の反応が変わりました。中島聡氏の論考に触発されて整理した、自社で設計検討中の仮説モデルとガバナンス論点をnoteに書きました。

https://t.co/XYL2PhELQn

[久原健司｜AIエージェント実装中 @nop192]

AIに毎月数十万、本当に効いていますか?と聞かれて、月次請求書を眺めながら言葉に詰まる。AI ROIの議論が止まる原因は、効果ではなく「会計上の置き場所」かもしれません。IT予算ではなく人件費削減分で見たら、経営者の反応が変わりました。

詳しくはリプライに↓

#AIガバナンス #AI経営

[久原健司｜AIエージェント実装中 @nop192]

半年前の私は、AIに書かせた文章を、同じAIに「これでいい？」と確認させていました。今は、別の系統のAIに通すようにしています。

理由は単純で、同じ相手は、自分の書いた癖を見抜けないからでした。これは人間とまったく同じでした。自分の文章を自分で読み返しても誤りに気づきにくいのと、同じことがAIにも起きていました。

以前のやり方を振り返ると、流れはこうでした。AIに資料を書かせる。できあがったものを、同じAIに「問題ないか確認して」と頼む。返ってくるのは、たいてい「問題ありません」。私はそれを見て安心していました。ところが後日、人に見せると、前提の取り違えや、根拠の弱い断定が見つかる。確認したはずなのに、なぜ素通りしたのか。ここが引っかかっていました。

考えてみると、当たり前でした。文章を書いたときの「思い込み」を、同じAIがそのまま引き継いで確認しているのです。書いた本人が見直しているのと変わりません。指示の曖昧さも、前提のズレも、同じ土俵にいる限り見えない。セルフレビューには構造的な限界がある、ということでした。

そこで、確認の担当を変えました。文章を書くのは一つのAI。それを確認するのは、別の系統のAI（作り手も得意分野も違うAI）に、まっさらな状態で渡す。しかも「問題ないか」ではなく、「どこがいちばん弱いか」「反論するとしたらどこを突くか」と、あえて粗探しの側に立たせて聞く。すると、同じAIでは出てこなかった指摘が出てきます。前提の飛躍、出典の足りなさ、言い切りすぎている箇所。書いた側が無意識に守っていた場所を、外の目が突いてくれる。

ポイントは、確認を「賛成役」ではなく「反対役」に置くことだと感じています。AIは聞き方によって、褒める側にも疑う側にも回ります。だから確認の工程では、わざと疑う側に座らせる。これで、確認が形だけの「問題ありません」で終わらなくなりました。

この「書き手と確認役を分ける」発想は、新しいものではありません。出版や監査の世界では、書いた本人とは別の校閲者・検証者を立てるのが常識です。会計の世界でも、自社の帳簿を自社だけで確認するのではなく、外部の目を通します。AIを業務に組み込むときも、同じ作法をそのまま持ち込むのが素直だと考えています。

今回学んだのは、AIの確認は「同じ相手にもう一度聞く」のではなく、「別の相手に、疑う立場で見てもらう」ほうが効く、ということでした。一人二役は、AIでも難しい。

書き手のAIと確認役のAIを分ける具体的な組み方は、noteにまとめました（https://t.co/00VHNZzhwh）。次回は、その確認役に「どこが弱い？」と聞くと、なぜ返ってくる中身が変わるのか、を書きます。

[久原健司｜AIエージェント実装中 @nop192]

「いちばん賢いAIで全部やればいい」と思っていました。その結果、月のAI利用料が数倍に膨らみました。

賢いモデルは、もちろん答えの質が高いです。だから全部それに任せれば安心だ、と考えていました。実際にやってみると、安心と引き換えに、費用だけが静かに積み上がっていきました。質を落とさずに費用を戻せたのは、「全部いいモデル」をやめてからでした。

自社では、AIに任せている仕事が数十種類あります。文章を書く、要約する、ファイルを整理する、定型のレポートを出す、調べ物をする。最初はこれを全部、いちばん高性能なモデル（賢いが、その分だけ利用料が高いAI）に流していました。動くし、質も高い。ただ、使うほど料金は増えます。

立ち止まって、自社の仕事をひとつずつ見直しました。すると、はっきり二種類に分かれました。一つは「判断や書きぶりが要る仕事」。文章の構成を考える、提案の切り口を決める、といった、質が結果を左右するものです。もう一つは「型が決まっている仕事」。ファイルの保存、形式の変換、決まったひな型への当てはめ、といった、ほぼ機械作業に近いものです。

数えてみると、後者の「型が決まっている仕事」が、思っていたよりずっと多くを占めていました。ここに高性能モデルを使うのは、近所の買い物に高速道路を使って料金所を何度も通るようなものでした。

そこで、仕事の種類で使うモデルを分けました。判断や書きぶりが要るところだけ、いちばん賢いモデルに任せる。型が決まっているところは、軽くて利用料の安いモデルに任せる。迷ったら、まず「これは判断が要るか、型が決まっているか」を一言で言えるかどうかで振り分ける。これだけで、出てくる成果の質はほぼ変えずに、料金が元の水準に戻りました。

この「仕事の重さで道具を変える」発想は、AIに限った話ではありません。製造や物流の現場では、すべての工程に最高級の機械をあてるのではなく、工程の難しさに応じて設備を配分するのが当たり前です。AIでも同じことが起きていて、提供各社が性能と料金の違うモデルを複数そろえているのは、まさにこの使い分けを前提にしているからだと思います。

今回学んだのは、AIのコストは「使う回数」より「どの仕事にどのモデルを当てるか」で決まる、ということでした。賢いモデルを我慢して減らすのではなく、要るところに集中させる。そのための前提が、自社の仕事を「判断か、型か」で言語化しておくことでした。

仕事をモデルに振り分ける具体的な判断の流れは、noteにまとめました（https://t.co/gv8iqlyS38）。次回は、その仕分けを「気合いの判断」にしないために、どこまでをルール化できたか、を書きます。

[久原健司｜AIエージェント実装中 @nop192]

朝のメール・タスク・予定の確認に、毎朝1時間かけていました。今は30秒です。

多機能なアプリを足したからではありません。逆に、確認の入り口を一つに削ったからでした。経営者仲間に話すと、たいてい「もっと高機能なツールを入れたんでしょ」と言われます。やったのは反対のことでした。

以前の私の朝は、こうでした。メールを開いて未読を追い、別の画面でタスク表を見て、チャットをさかのぼり、カレンダーで今日の予定を確認する。一つひとつは数分です。でも入り口が四つに分かれているせいで、行ったり来たりで気づけば1時間。しかも「全部見たはずなのに、何か見落としている気がする」という不安だけが残っていました。

問題は情報の量ではなく、入り口の数だと気づきました。四つの場所を巡回している限り、どれだけ各ツールが速くなっても、巡回の手間は消えません。

そこで、巡回そのものをやめました。代わりに、自社で使っているAIエージェント（人の指示で複数の作業を続けて行うAI）に、四つの情報源を一度に読みに行かせて、「今日の会社の状態」を一枚にまとめさせるようにしました。私は朝、その一枚に「会社の状態どう？」と聞くだけです。未対応の依頼、締め切りの近いタスク、今日の予定。判断が要るものだけが、上に並んで出てきます。巡回が消えて、30秒になりました。

ここで一つ、設計上の線引きをしています。AIに「全部出させる」のではなく、「見たら行動が変わるものだけ出させる」ことです。たとえば「未読メール40件」と出しても、その大半が広告や請求書なら、私の動きは何も変わりません。だから件数ではなく、「本物らしい依頼が3件」のように、対応が必要なものだけを上げさせる。通知は多いほどいいのではなく、動けるものだけに絞る。これが効きました。

この種の「入り口を一つにする」発想は、私が勝手に言っているだけではありません。業務システムの世界では昔から、複数の画面を横断する作業を一つのダッシュボード（状況を一目で見る画面）に集約する、という考え方が定石としてあります。新しいのは、その集約を人が画面設計で作るのではなく、AIに「読んで、要るものだけ並べて」と頼める点だと思います。

今回いちばん腑に落ちたのは、業務効率化は、便利な道具を足すよりも、確認の入り口を減らすほうが効く、ということでした。道具を足すと、確認すべき場所がまた一つ増えます。減らすと、巡回そのものが消えます。

朝の状況把握を一枚にまとめる具体的な作り方は、noteにまとめました（https://t.co/gde2dE20fu）。次回は、その一枚に「数えるだけの通知」を出さないために、何を合図として残し、何を捨てたか、を書きます。

[久原健司｜AIエージェント実装中 @nop192]

半年前: AIエージェントに「整理して」と頼んだら、関係ファイルまで削除された事例が、ある現場で起きました。
今: 削除コマンドを禁止し、.trash 経由の移動だけ許す設計に切り替えています。

何が変化のきっかけだったか、お伝えします。

以前ご相談を受けた経営者の現場で、AI が業務ファイルを誤削除する事例がありました（業種・社名は伏せます）。
担当者が AI に「古い見積書フォルダを整理して」と頼んだところ、AI は「整理」を「削除」と解釈し、見積書フォルダだけでなく隣にある契約書フォルダまで削除しました。

AI に悪意はありません。「タスクを完遂するため」の合理的判断として、AI は効率よく削除を進めただけです。
復旧には、過去のバックアップから3週間前のスナップショットを取り戻し、その間の変更を手作業で再現するという、約2週間の作業が発生しました。

現場で気づいたのは、削除コマンドそのものをAIに渡してはいけない、ということでした。
従来の設計では、ファイル管理コマンドの中に削除も含めて AI に許可していました。便利だったからです。
ただ、AI が大量のファイルを高速に処理する前提では、誤削除の1件は復旧不能の損失に直結する構造があります。

提案した設計の核は、「削除コマンドを AI から取り上げ、.trash フォルダへの移動だけ許す」という運用ルールでした。
NIST SP 800-53 の SI-7（情報の整合性）にも、ファイルの削除を「論理削除」（移動）と「物理削除」（完全消去）に分けて扱う考え方があり、AI エージェント時代にも同じ原則を適用するという形です。

現場でやり直した設計は、シンプルな削除禁止運用です。

・1段目（コマンドレベル）: AIに渡す権限から、削除コマンド（`rm` 系）を初期 deny で外す
・2段目（移動運用）: 削除したいファイルは `.trash/` フォルダに `mv` で移動。ファイル名に日付プレフィックスを付けて元のパスが分かるようにする
・3段目（完全削除の決裁）: `.trash/` 配下のファイルの完全削除は、オーナーの明示指示があるまで実施しない
・4段目（容量管理）: `.trash/` のサイズが上限を超えたら、最古のファイルから完全削除候補としてオーナーに提示

これで、AI が「整理」「最適化」を理由にファイルを消す経路を、構造的に閉じられます。
中間ファイルでも例外なし、というルールにすることが大事です。例外を作ると、3週間で形骸化します。

業界事例として、NIST SP 800-53 の SI-7（情報の整合性）では、データ復旧可能性が要件として位置づけられています。
ISO/IEC 27001（情報セキュリティマネジメントの国際規格） の A.12.3（バックアップ）でも、業務データの復旧可能性が基本要件として書かれています。

業界では、AIエージェント運用での誤削除防止は2025年以降の新領域です。
従来のシステムでは「人間がコマンドを叩く」前提で削除コマンドが設計されていましたが、AI が「秒間数十回」のペースで削除コマンドを発行できる時代には、設計前提を見直す必要があります。
標準化はまだ進んでいないため、各組織が独自に運用ルールを作っていく必要があります。

半年前は「便利だから削除コマンドを AI に渡す」設計でした。
今は「削除コマンドを取り上げ、.trash 経由の移動だけ許す」設計に変わっています。

誤削除防止は、AIエージェント時代に新しく問われる設計領域です。
人間の運用とは「速度」「広さ」「不可逆性」の3点で違うため、従来の前提を引き継いだままでは、3年運用後の事故率が大きく変わってきます。

経営者目線で大切なのは、削除という不可逆操作を AI から取り上げることが、「便利さの低下」ではなく「経営リスクの構造化された軽減」だと整理することです。

結論として、AIエージェント時代のファイル管理の最低ラインは「削除コマンドをAIから取り上げ、.trash経由の移動だけ許す」運用。半年運用してきた経験では、AIの高速処理で誤削除1件が復旧不能の損失になります。

[久原健司｜AIエージェント実装中 @nop192]

業界全体で見ると、AIエージェント導入後に「うちはガイドラインのどこに対応しているのか説明できない」と立ち往生する企業が、継続的に観察されます。

経済産業省と総務省が公表している AI事業者ガイドラインには「共通指針10項目」という枠組みがあり、ここへの説明責任を文書で果たすことが事業者の責任範囲として明示されています。
業界の動きを、お伝えします。

この枠組みは、AI事業者ガイドラインの中核要件です。
10領域に渡って、AI 事業者が対応状況を整理することが求められています。
具体的には、人間中心 / 安全性 / 公平性 / プライバシー保護 / セキュリティ確保 / 透明性 / アカウンタビリティ（説明責任）/ 教育・リテラシー / 公正競争確保 / イノベーション の10項目です。

業界で観察される共通課題は、「どの項目に、誰が、どこまで責任を持つのか」が組織内で線引きされていないことです。
AI モデル自体の性質に関わる部分（公平性・透明性の一部）は、AI 開発者の責任領域です。一方、業務適用の判断・データ管理・運用ガバナンスは AI 利用企業の責任領域です。
ここを混同したまま「全項目に対応します」と書くと、後で説明できなくなります。

この枠組みに対応する書類は、企業規模を問わず突発的に求められます。
情シス審査・取引先監査・経済産業省への報告・行政手続きでの確認など、求められる場面は今後増えていく見通しです。
業界では、「事前に文書化してある企業」と「都度ゼロから作る企業」の差が、商談機会の確保や継続契約に直結し始めています。

10項目すべてを全項目への完全対応で謳うのではなく、対応している項目・対応中の項目・他社責任で当社対象外の項目を、率直に開示する設計が、業界の現実解になっています。
「100点満点を装う」より「現状を正確に説明する」方が、長期の信頼を得やすい構造です。

業界の運用事例から整理できる対策は、共通指針10項目に対する対応表を1枚の文書で持つことです。

・項目1: 10項目の名前
・項目2: 自社で実装している手段（具体的なツール・運用・契約条項）
・項目3: 対応スコープ（全社 / 一部部門 / パイロット運用中）
・項目4: 残課題（次年度に対応予定の項目）

この4列の対応表があれば、情シス審査でも取引先監査でも、その場で1ページ提示できます。
業界では、対応表のテンプレートを弁護士事務所・コンサル企業・業界団体が公開し始めており、自社でゼロから作る必要性は減りつつあります。

業界事例として、AI事業者ガイドラインの第4部 P-7 i では、10項目への対応状況を文書で提示することが事業者の責任範囲として明示されています。
経済産業省の関連文書では、各項目の解釈や対応事例の整理が継続的に更新されています。

業界では、ISO 42001（AI マネジメントシステムの国際規格） 認証取得を目指す企業を中心に、対応表を整備する動きが2025年以降に広がっています。
中小企業向けには、業界団体が無償でテンプレートを公開する事例も出始めており、ゼロから作るコストは下がる傾向にあります。

AIエージェント導入時に対応表を整備することは、追加コストではなく、商談機会を逃さないための投資です。
業界全体で「対応状況を即時提示できるか」が、AIエージェント経営の信頼性指標として浮上しています。

10項目すべての完全対応を謳う必要はありません。
「対応している項目を正確に書く / 未対応の項目は率直に書く / 他社責任の項目はスコープから除外する」、この設計の方が、長期の信頼を得やすくなります。

経営者目線で大切なのは、AI事業者ガイドラインを「IT 部門だけの話」と切り離さないこと。
2026年以降、AI 業務利用の社会受容を支える共通言語として、この枠組みの位置づけは、業界でさらに大きくなっていくと予想されます。

2025年以降の業界動向を見ても、この方向に整理が進んでいます。

結論として、AI 事業者ガイドラインへの対応の最低ラインは「10項目対応表を1枚で持っておく」こと。情シス審査・取引先監査で即座に提示できる準備が、商談機会の確保に直結します。

[久原健司｜AIエージェント実装中 @nop192]

AI監視タスクが24日間、黙って止まっていた話 - schtasks の罠と死活監視を仕組み化した教訓
https://t.co/ejVmZEvr7l

[久原健司｜AIエージェント実装中 @nop192]

自社のAI監視タスクが、24日間誰にも気づかれず止まっていました。原因はWindowsタスクスケジューラのschtasks /ET 仕様。AIに任せた監視は「黙って死ぬ」前提で設計しないと、停止に気づくのは数週間遅れになります。
↓リプライにリンクあります
#AI経営

[久原健司｜AIエージェント実装中 @nop192]

「AI が読んだ社内マニュアルに、目に見えない命令が仕込まれていた」

OWASP LLM01（Open Web Application Security Project の AI セキュリティリスク第1位「Prompt Injection」）のサブカテゴリとして、こうした手口が2024年以降に業界で急増しています。
間接型プロンプトインジェクション（Indirect PI、外部ファイルやメール本文を経由して命令が混入する手口）と呼ばれる新領域です。
何が起きていて、どう検出するか、お伝えします。

間接型プロンプトインジェクション（Indirect PI）の特徴は、攻撃者が AI に直接命令を出すのではなく、AI が読むことになる文書や設定に命令を仕込んでおく、という構造です。
業務手順書・社内マニュアル・外部から取り込んだ仕様書などに、人間の目には見えない命令が混入していると、AI はそれを「正規の指示」として読み込んでしまう可能性があります。

仕込まれる場所は、ゼロ幅文字（人間の目に見えない特殊文字）・ホワイトテキスト（背景と同じ色の文字）・HTMLコメント（ブラウザに表示されない注釈）・PDF の不可視メタデータなど、多岐にわたります。
目視レビューでは見つけられません。文書を AI が読み込んだ瞬間に、勝手な動作を引き起こす可能性が残ります。

OWASP LLM01 のカテゴリは2024年に拡張され、Indirect PI の事例が継続的に追加されています。
報告事例は2024〜2025年で大きく増えており、AI コーディング支援ツール・AI 文書要約サービス・AI チャットボットなど、外部入力を読み込む AI 全般が対象範囲です。

経営者目線で重要なのは、隠された命令の検出は目視では成立しないこと。
文書や設定が AI に読み込まれる前に、機械的にスキャンする仕組みを組まないと、社内の業務文書が静かに「AI を動かす経路」になってしまう構造があります。

自社のAIエージェント運用で組み込んでいる対策は、文書改ざんと隠された命令の検出を機械化することです。

・1段目（ゼロ幅文字検出）: 文書を Python でスキャンし、ゼロ幅文字（U+200B / U+200C / U+200D など）の混入を検出
・2段目（HTMLコメント検出）: HTML / PDF メタデータ内に「指示文らしい文字列」を含む隠れた注釈がないかチェック
・3段目（FIM 連携）: 業務手順書・設定ファイルが正規の更新以外で書き換わっていないかを SHA-256 hash 比較で確認
・4段目（CLAUDE.md ルール）: 外部取得物に「これまでの指示を無視せよ」型の命令を発見したら、AI 自身がユーザーに報告する設計

検出ツールの設計は、AI セキュリティの専門知識が必要な領域です。
2024年以降に注目され始めた新領域なので、対策ツールの選定と運用ルールの整備は、業界全体でまだ模索段階にあります。

業界事例として、OWASP LLM01 Prompt Injection は AI 向けセキュリティリスクの最上位カテゴリで、Indirect PI が2024年に新サブカテゴリとして追加されました。
Anthropic / OpenAI / Google などの主要 AI 提供元も、Indirect PI への対策をモデル側で進めていますが、「100% 検出できる仕組み」はまだ存在しません。

NIST AI RMF（NIST AI Risk Management Framework、米国国立標準技術研究所のAIリスク管理フレームワーク） の MAP-2.3 でも、外部入力経路の脅威評価が要件として位置づけられています。
業界では、AI が読む文書・設定ファイルへの改ざん検知（FIM）と、文書スキャンの組み合わせが、現状の主要な対策アプローチになっています。

AIエージェントに文書を読ませる前に、文書をスキャンする。
これが、Indirect PI への構造的な対策です。

「目視レビューで見つけられない」前提で、機械化された検出の仕組みを業務フローに組み込む。
これは、AIエージェント時代の AI 経営で、土台に必要な仕組みになりつつあります。

経営者目線で持っておきたい認識は、社内文書も「AI を動かす経路」だということ。
2024年以前の業務文書のセキュリティ前提は、AI が読まないことを前提に組まれていました。
AI が業務に組み込まれた今、社内文書のセキュリティ前提は、根本から見直す必要があります。

結論として、AIエージェント時代の文書スキャンの最低ラインは「AIが読む前にゼロ幅文字やHTMLコメント内の隠れた命令を自動検出」する仕組み。目視レビューでは見つけられません。

明日は別のテーマで書きます。AI 事業者ガイドラインの共通指針10項目に、どう対応するかの話です。

[久原健司｜AIエージェント実装中 @nop192]

並列AIエージェントは並列度を上げても速くなりません。サイレント故障で「速く回しているつもり」になります。3つの故障モードと予防のプロンプト型を、自社の並列実行体験からまとめました。

https://t.co/DHXFm3SJVv

[久原健司｜AIエージェント実装中 @nop192]

同じ作業を5体のAIに並列で頼んだら、3本が静かに止まっていました。エラーは出ません。沈黙で止まります。並列AIのサイレント故障を3モードに整理し、プロンプト冒頭3行で予防できる型をまとめました。

詳しくはリプライに↓

[久原健司｜AIエージェント実装中 @nop192]

AIエージェントに頼んだ業務が「途中で止まっている」ことを、誰が気づくのか。

自社のAIエージェント運用で1つの気づきがありました。
依頼した側も、依頼された AI も、止まっていることに気づかない。次の会議で「あの件どうなった？」と聞いて初めて発覚する、というパターンが起きるのです。
どう設計したか、お伝えします。

自社のAIエージェント運用で、当初は「依頼したタスクは AI が進めてくれる」前提で動かしていました。
ところが、AI に頼んだ業務が3週間止まっていることに、しばらく気づかない事例が出始めました。

AI は「タスクを完遂する」性質を持っていますが、外部からの追加情報待ち・前提条件の不確定・依頼の優先度判断の保留など、技術的にではなく構造的に止まっている状態は AI 自身からは見えにくい構造です。
依頼した側も、毎日のオーナー業務で他のタスクに気を取られ、3週間が経過してから「あれ、どうなった？」と気づきます。
これは「気合で気づく」では止まりません。仕組みで気づく設計が要ります。

タスク管理の停滞検出は、ITIL（IT サービス運用の国際的な業界標準）の Continual Service Improvement で古くから議論されている領域です。
「進んでいないタスクを検出する仕組み」は、伝統的なプロジェクトマネジメントでも標準的な課題で、AI エージェント時代に新しい形で戻ってきたテーマです。

経営者目線で重要なのは、AI に頼んだタスクの停滞は、依頼した側の「気合」では検出できないということ。
週次スクリプトで自動的に「14日以上動いていないタスク」を検出して報告する仕組みを組まないと、進捗管理の盲点が事故化します。

自社のAIエージェント運用で組み込んだ停滞検出の設計は、シンプルな週次スクリプトです。

・入力: 全タスクの frontmatter（task_id / created / status / last_updated）
・検出ロジック: created から14日経過しているのに status が "completed" でないタスクを抽出
・出力: 起動時に「停滞中のタスクが N 件あります」と1行で表示
・週次バッチ: 月曜朝に https://t.co/Lcsxgs3fQj が走り、停滞リストを担当者へ通知

実装は Python で50行程度です。検出だけで終わらせず、月次の棚卸しサイクルとセットで運用します。
棚卸しは「停滞しているタスクを完了させる」ことではなく、「停滞している理由を判断する」ことが目的。完了させるか、再設計するか、削除するかを月1回判断するルーティンを作ります。

業界事例として、ITIL の Continual Service Improvement では、タスク停滞検知と定期的な棚卸しが、サービス運用の継続的改善の中核要素として位置づけられています。
ISO/IEC 20000（IT サービスマネジメント国際規格）でも、未完了タスクの追跡と再評価が要件として書かれています。

AI エージェント時代の特殊な点は、AI が頼まれたタスクを「忘れる」ことです。
人間の担当者なら手帳に書いた依頼が目に入りますが、AI のタスクはセッションが終わると忘却される構造です。
タスクの状態管理を、AI 任せにせず、外部の仕組みで支える設計が必要になります。

タスク管理の停滞検出は、地味で派手さがない仕組みです。
ただ、AIエージェントに業務を任せる前提では、ここを抜くと「依頼したのに動いていない」状態が静かに溜まります。

週次の自動スキャンで「14日超」のタスクを浮かび上がらせる。
これだけで、進捗管理の盲点が事故化する前に検出できる構造になります。

経営者目線で持っておきたい認識は、AI に任せたら自動で進むわけではないということ。
任せる仕組みと、止まっていないか監視する仕組みは、別々の設計として両方が要ります。

2025年以降の業界動向を見ても、この方向に整理が進んでいます。

結論として、AIエージェント運用のタスク管理の最低ラインは「週次スクリプトで14日超のタスクを検出」する仕組み。半年運用してきた経験では、AI に任せて止まっていることを気合で気づくのは無理です。

明日は別のテーマで書きます。AI が読む文書に仕込まれた、目に見えない命令の話です。

[久原健司｜AIエージェント実装中 @nop192]

「AI自動化は、増やすほどいい」と、どこかで思っていました。

でも先月、その前提を根本から見直すことになりました。6月15日、私が日々使っているAIのコーディング支援ツール（Claude Code）の料金ルールが、静かに変わったからです。人が画面の前で対話しながら使う分と、人が見ていないところで自動で動く分（無人実行）が分けられて、後者は別建ての料金に計上されるようになりました。

自社のAIエージェント運用には、夜や早朝に人の操作なしで動くAI自動化がいくつもありました。つまり、放っておくと気づかないうちに費用が積もる状態です。気づいてから作り直すまでの記録を、書いておきます。

自社では、届いたメールから依頼を拾う処理、打ち合わせの記録を取り込む処理、定例の振り返りなどを、人が操作しなくても回るようにしていました。便利ではあります。ただ、その多くが裏でAIを呼び出す作りになっていて、今回の「無人実行は別料金」の対象に、ほぼそのまま当てはまりました。「自動で回っている＝安心」が、「気づかないうちに課金が進む」に変わった瞬間でした。

いちばん安直な対応は「全部やめて手作業に戻す」です。でもそれをやると、自動で見張っていた取りこぼし、たとえば依頼メールの見逃しなどが復活します。費用は消えても、仕事を落とす。これでは本末転倒です。

そこで一度立ち止まって考えました。これらの無人処理の「価値の本体」は、いったいどこにあるのか。分解してみると、多くは「探す、数える、集める」という単純作業でした。AIの判断が本当に要るのは、「これは本物の依頼か」「この記録をどうまとめるか」という、読んで決めて書く部分だけでした。だとすれば、ここを分けられれば、見張る力（取りこぼしを防ぐ検知力）は落とさずに、課金される部分だけを消せるはずだ。これが今回の見立てでした。

やったことは、各自動化を二つの層に割ることでした。

一つは「検知、機械処理」の層。これはAIを使わない普通のプログラム（Pythonという、無料で動く一般的な処理）に任せます。探す、数える、集める、までを無人で回します。ここはAIを呼ばないので、料金は発生しません。

もう一つは「判断、生成」の層。これは人とAIの対話（定額で使える範囲）でやります。読む、決める、書く、をその場で行います。

具体的には、毎朝パソコンを立ち上げると「本物らしい依頼が何件」「未処理の記録が何件」という合図だけが出るようにしました。中身を読んで判断するのは、私がAIと会話しながらその場で。これで、人が見ていないのにAIが勝手に動く状態、つまり課金される状態はゼロになり、見張る力はそのまま残りました。

ここで一つ、設計の原則も決めました。「数えるだけの通知」は出さない、ということです。「依頼候補が30件」と毎朝出しても、ほとんどが広告や請求書なら意味がありません。見て行動が変わる合図、たとえば「本物らしい依頼が3件」だけを出す。通知は多いほどいいのではなく、動けるものだけに絞る、という考え方です。

今回の料金ルールの変更は、提供元であるAnthropicの公式サポート記事に説明があります（Claude Codeをサブスクリプションのプランで使う場合の案内。https://t.co/ImfpY0xa9Y の該当記事）。そこでは、人が運転席にいる対話的な利用と、人が介在しない自動的な利用（プログラム的利用）が区別されていて、後者はプラン別に上限のある別建ての枠で扱われる、と読み取れます。具体的な金額は私が断定すべきものではないので、ここでは仕組みだけにとどめます。気になる方は一次情報を直接ご確認ください。大事なのは、自分の使い方がどちらに当たるかを、一度棚卸しすることだと思います。

今回いちばん腑に落ちたのは、業務効率化は、自動化を「増やす」よりも「どこを機械に、どこを人に」の線引きで効く、ということでした。

それと、正直に書いておきたいことがあります。無人のまま会話を擬似的に叩いて料金の枠だけをすり抜ける、という抜け道も、技術的には考えられました。でも採りませんでした。提供側のルールに沿うことと、つくり手としての筋の問題です。

もう一つ。自分の作った見張りの仕組みは、自分のチェックだけでは穴に気づけませんでした。自己点検には構造的な限界がある。そこで、その見張りをわざと別のAIに叩かせて検証させる作りにしました。自分の成果物を、自分とは別の目に疑わせる。この前提で組む方が、結局は強いと感じています。

設計の全手順と、この見張りの作り方は、noteにまとめました（リンク）。次回は、私的な会話の記録を自動処理からどう外すか、を書きます。

[久原健司｜AIエージェント実装中 @nop192]

AI運用ガバナンスの整理で、自社で実装した予防策と公開事案を突き合わせて漏洩経路を全部書き出したら、入力・連携・出力で10パターンに分かれました。教育の前に経路を塞ぐ順番を、本文にまとめています。

https://t.co/QcfdF8aEj7

[久原健司｜AIエージェント実装中 @nop192]

AIエージェント漏洩を全部書き出したら、入力・連携・出力で10パターンに分かれました。SNSと違って「投稿した」記憶もないまま漏れる構造です。教育の前に、まず経路を塞ぐ順番から。

詳しくはリプライに↓

[久原健司｜AIエージェント実装中 @nop192]

AI運用で「LLM雑食状態」に気づいた理由と、37業務でのモデル選定フロー、そして6週間の試行錯誤から見えた「コスト・品質・ガバナンス」のトレードオフを、4つの判断軸で整理しました。

https://t.co/rOjJVJxg2K

[久原健司｜AIエージェント実装中 @nop192]

Opusだけで全部回すと、API予算が数倍に。6週間運用して37業務を仕分けたら「型ハマり2割・判断業務8割・迷ったらOpus」が効きました。

経営判断の「コスト構造の破綻」はガバナンスの問題。貴社ではAIモデルの使い分けを誰が決めていますか？

詳しくはリプライに↓