AIと弁護士実務

目次

第１　結論第２　アプリ停止とPC全体のフリーズを区別する第３　Application Hang及びAppHangB1の読み方第４　発生直後に残す記録第５　セキュリティソフトの関与をどう評価するか第６　再インストールより先に行うこと第７　正常再起動の記録第８　メーカー又は開発元へ伝える事項第９　本記事の限界第１０　出典・参考資料

特定のアプリだけが「応答なし」になって終了しても，Windows全体のフリーズとは限らない。
まず他のアプリ，マウス，タスクマネージャー及び通常の再起動が動くかを確認し，停止範囲を分ける必要がある。

Application Hang又はAppHangB1は，アプリが応答しなかった事実を示すが，それだけで原因となったDLL，セキュリティソフト又はハードウェアを確定する記録ではない。

第１　結論

特定アプリだけの停止は，①未保存データと外部送信の成否確認，②発生時刻・アプリ版・操作の記録，③ApplicationログとWERの保全，④同じ条件での限定的な再現確認，⑤更新・修復・除外設定の順で調べる。
PC全体の強制終了は最後の手段である。

第２　アプリ停止とPC全体のフリーズを区別する
観測暫定評価他のアプリが動くアプリ単位の停止を優先スタートメニューから正常再起動できるその時点でWindowsの終了処理が動いていたマウスもCaps Lockも遠隔接続も反応しないWindows全体の停止（ハードハング）を優先して検討再起動後にEvent 41・6008だけがある前回の終了が正常でなかった記録であり原因は別途確認

同じ日にPC全体の停止とアプリ単位の停止が起きることもある。
二つを一つの原因で説明しようとせず，時刻ごとに別の事象として整理する。

第３　Application Hang及びAppHangB1の読み方

Windows Error Reportingは，アプリ障害，カーネル障害，応答しないアプリ等の問題をMicrosoftへ報告する仕組みである。
アプリがWindowsメッセージへ一定時間応答せず，利用者が操作すると「応答なし」と表示されることがある。

イベント名AppHangB1等は停止の分類に役立つが，障害モジュールの記載があるクラッシュと同じ精度で原因を示すとは限らない。
ハッシュやバケットが同じ事象の反復かを確認する。

第４　発生直後に残す記録

①発生時刻，アプリ名，版数及び32ビット・64ビット
②直前に行った検索，読込み，保存又は送信
③未保存データと外部処理の成否
④タスクマネージャーでのCPU，メモリ及びディスク使用率
⑤Applicationログ，信頼性履歴及びWERのイベント名・バケット

ログやダンプには文書名，利用者名その他の秘密情報が含まれ得る。
共有前に対象範囲を絞り，原本と加工版を分ける。

第５　セキュリティソフトの関与をどう評価するか

監視DLLが対象プロセスへ読み込まれていた事実だけで，その製品を原因と断定してはならない。

①アプリとセキュリティソフトを最新にする
②同じ操作で再現するかを確認する
③ベンダーが案内する正式な除外又は互換性確認だけを限定的に行う
④保護機能を無期限に停止しない

（続きを読む...）Windows 11で特定のアプリだけ「応答なし」になる場合の調べ方―Application Hang，AppHangB1及びセキュリティソフト（AI作成）

目次

第１　結論第２　３画面と２画面で何が変わるか第３　最初に停止範囲を分ける第４　変更前に画面構成を記録する第５　２画面比較の読み方第６　LiveKernelEvent及びTDRの位置付け第７　接続端子を変更しないでできる対策第８　再発時の確認表第９　本記事の限界第１０　出典・参考資料

３画面から２画面へ減らした後にフリーズが止まっても，直ちに「３台目のモニターが故障原因」とは断定できない。
変わったのは台数だけでなく，GPUの出力経路，解像度，向き，ケーブル及びドライバーが同時に関係し得るからである。

切分けの目的は，仕事を長期間２画面で我慢することではなく，再現条件を一つずつ狭め，最小の変更で３画面へ戻すことにある。

第１　結論

複数画面時だけ固まる場合は，まず停止の範囲を確認し，現在の画面構成を記録した上で，３画面と２画面を一定時間比較する。
２画面で安定したことは表示経路を優先して調べる根拠になるが，原因の確定ではない。

第２　３画面と２画面で何が変わるか
変化する要素確認事項GPUの出力負荷各画面の解像度，リフレッシュレート及び同時出力数接続経路どのGPUのどの端子へ接続しているか画面構成主画面，横・縦表示，拡大率及び配置ケーブル等ケーブル，変換アダプター及びドックの有無

３画面から２画面へ変更する試験は，これらをまとめて軽くする試験である。
そのため，効果があった後は，台数，特定端子，縦表示等を一つずつ戻す必要がある。

第３　最初に停止範囲を分ける

①特定のアプリだけが「応答なし」になった
②画面更新だけが止まり，音声や遠隔接続は生きていた
③マウス，キーボード及び遠隔接続を含むWindows全体が止まった
④強制終了後にEvent 41又は6008だけが残った

表示停止はPC全体の停止と見分けにくい。
Caps Lock表示，別PCからの疎通，音声及び時計の更新など，強制終了前に確認できた事実を残す。

第４　変更前に画面構成を記録する

①各ディスプレイの番号，製品名，解像度，リフレッシュレート及び向き
②主画面とWindows上の配置
③GPU名，ドライバー版及び各接続端子
④ケーブル又は変換アダプター
⑤変更日時と，変更後に実際に使った時間

Windowsでは設定の「システム」―「ディスプレイ」で識別，配置及び複数画面の設定を確認できる。
記録がなければ，安定化後もどの差が効いたか判断できない。

第５　２画面比較の読み方

比較期間は一律ではない。
通常業務を同程度行い，再発しない期間が従前の発生間隔を十分に上回れば，手掛かりになる。
ただし，偶然再発しなかった可能性は残る。

（続きを読む...）Windows 11で３画面・複数ディスプレイ使用中にフリーズする場合の切分け―２画面比較，縦表示，GPU及び接続端子（AI作成）

目次

第１　裁判実務のAIは，賢さに加えて何を競うのか１　結論―能力と，検証した経験を再利用する仕組みを併せて考える２　記憶が増えたことと，仕事が良くなったことは違う第２　ここでいうスキルとは何か１　モデルの内部を学習し直すこととは区別する２　よいスキルは，結論よりも判断条件を残す第３　改善を報告する研究と，効果が小さかった研究をどう読むか１　SkillsBench―人が整備したスキルで改善した実験２　SWE-Skills-Bench―平均の改善が小さかった反対研究３　同じスキルでも，実行環境と手順の構成で結果が変わる４　「解く能力」「経験を手順へ変える能力」「手順を使う能力」は分けて見る５　経験の蓄積では，追加だけでなく選別と修正も考える第４　裁判準備の経験を，次にも使えるスキルへ変える１　失敗の感想を，検査可能な条件へ変える２　一つのスキルに残す情報３　登録までと，登録後の循環を分ける第５　裁判書面の準備では，どこをスキル化するか１　引用と根拠の対応を確認する工程２　新しい資料が来たときの影響確認３　出力後の確認までを仕事の単位にする第６　蓄積したスキルが役立ったかをどう測るか１　モデルとスキルを別々に変えて比べる２　呼び出し，手順の実行，成果物の品質を分ける３　人の確認を含めた総作業時間で評価する第７　増やし続けると，かえって使いにくくなる場合もある１　古い指示と過剰な手順を見直す２　更新する条件と，廃止する条件を決める３　外部のスキルは，文章だけでなく同梱物も確認する第８　裁判実務で残る，人の判断と検証の責任第９　出典
第１　裁判実務のAIは，賢さに加えて何を競うのか
１　結論―能力と，検証した経験を再利用する仕組みを併せて考える

裁判実務で使うAIの勝負どころは，「どれだけ賢いか」から「有益なスキルをどのように貯め，次に活かすか」へ移っているのか。
現時点の研究からいえるのは，モデルの能力に代わってスキルの蓄積だけが重要になったということではなく，モデルの能力に加えて，経験を再利用可能な手順へ変え，必要な場面で使い，効果を確かめる仕組みが重要な検討対象になっているということである。

本記事は，令和８年１１月１日を調査基準日とし，日本の弁護士が裁判準備，資料確認及び書面作成を補助するAIを使う場面を考える。
海外のAI研究と開発元の技術資料を手掛かりにするが，日本の裁判実務で勝訴率や作業時間の改善が実証されたという意味ではない。
以下では，研究者が報告した結果と，それを踏まえた実務上の提案を区別する。

２　記憶が増えたことと，仕事が良くなったことは違う

過去の会話を保存しただけでは，次の案件で何を使えばよいかは決まらない。
また，手順書の数が増えたこと，AIがその手順書を呼び出したこと，その結果として成果物の誤りが減ったことも，それぞれ別に確かめる必要がある。

実務で目指すべきなのは，成功例を大量に残すことだけではない。
どの条件で使える手順なのか，どの失敗を防ぐのか，どの場合には使わないのかを明らかにし，別の課題でも役立つかを確かめた上で再利用することである。
この考え方は，本ブログの法律事務所の暗黙知・経験知をAIで引き継ぐ方法で扱った判断条件，反例及び更新責任と，生成AIの評価・改善で扱った検証方法を，一つの運用として結び付けるものである。

第２　ここでいうスキルとは何か
１　モデルの内部を学習し直すこととは区別する

Anthropicが説明するAgent Skillsは，指示，スクリプト及び参考資料などをまとめ，必要な場面でエージェントが利用する仕組みである。
必要な情報を段階的に読み込む設計も示されている。
本記事で主に扱うのは，このようにモデルの外側へ保存して再利用する手順であり，モデルの重みを更新する学習そのものではない。〔Anthropicの技術資料〕

用語を整理するなら，資料庫には判断の根拠となる原資料を，会話履歴には過去のやり取りを，スキルには次の仕事で実行すべき条件付きの手順を置く，という役割分担が考えられる。
これは実務上の整理案であり，製品ごとの機能名を統一する定義ではない。
原資料を基に引用を確認する仕事では，資料の保存と，その資料をいつ，どの順序で確認するかという手順を，併せて考える必要がある。

２　よいスキルは，結論よりも判断条件を残す

例えば「判例を確認する」という指示だけでは，何をもって確認が終わったかが分かりにくい。
これを「引用予定の命題ごとに，原文の位置，誰の発言か，適用条件，限定及び書面中の引用箇所を対応させる」という手順へ変えると，成果物として確認すべきものが具体化する。

ただし，この手順を作っただけで誤引用が減ると断定することはできない。
次の課題で実行できたか，対応表の内容が原文と合っているか，人の修正時間が増えすぎていないかまで確認して，初めて採用の適否を判断できる。
基本的な手順書の作り方は，弁護士のClaude Code Skills活用法を参照されたい。

第３　改善を報告する研究と，効果が小さかった研究をどう読むか
１　SkillsBench―人が整備したスキルで改善した実験

（続きを読む...）裁判実務のAIはスキルの蓄積で変わるか―経験の再利用，効果の検証及びモデル能力との関係（AI作成）

目次

第１　対象と結論第２　データの移行と利用時の処理を分ける第３　確認するデータの流れ第４　契約・個人情報・秘密情報の確認第５　接続前と接続後に試すこと第６　提供者への質問と導入判断第７　関連記事と一次資料
第１　対象と結論

AIやクラウドの説明で「データを動かさずに利用できる」と書かれていても，元の保存先を維持することと，別のサービスがデータを取得・処理・一時保存することは分けて確認したい。
全量の移行や複製を避ける構成でも，利用時の通信やキャッシュまでなくなるとは限らない。

本記事は，企業や法律事務所が，別クラウドにある資料をAI・分析サービスへ連携するときの確認事項を整理する。
令和８年１１月１日を確認の基準日とし，Googleのクロスクラウドキャッシュの説明を具体例に使うが，全ての「ゼロコピー」製品が同じ仕組みであるという説明ではない。
製品の安全性を一括判定したり，特定の構成について適法性を保証したりするものでもない。

導入の判断では，①どのデータが，②誰に，③どこで，④何のために処理され，⑤どれだけ残り，⑥誰がアクセスを止められるかを，実際の契約・設定・記録に対応させる方法が考えられる。
資料を読むだけの連携か，更新・送信その他の操作もできる連携かも区別する。

第２　データの移行と利用時の処理を分ける

Googleの令和８年９月付けの公式説明は，BigQuery及びLakehouse向けのクロスクラウドキャッシュをプレビューとして発表し，別クラウドのデータから必要なデータを取得し，Google Cloud内にキャッシュを保存する仕組みを説明している。
ファイル全体ではなく，問い合わせに必要な列のデータ等を扱うという説明である。
これは提供者が公表した当該機能の説明であり，本記事が利用環境で通信・保存を実測した結果ではない。

この例から分かるのは，元のデータを別の基盤へ全量移行しないことと，利用時にデータの一部が別の場所へ渡ることは両立するという点である。
「移動しない」という短い表示だけから，外部通信，一時保存又は他の事業者による処理が一切ないとは判断できない。

また，技術用語としてのクラウド間の転送と，個人情報保護法上の提供又は委託の評価は同じ問いではない。
個人情報保護委員会のＱ＆Ａ（Ｑ７－53）も，クラウドサービスの提供事業者が個人データを取り扱うこととなっているかを判断の基準としている。
通信があることだけで法的な違反を決めず，通信が少ないことだけで契約や情報管理の確認を終えないようにする。

第３　確認するデータの流れ

導入前には，次の表を実際の構成に沿って埋める方法が考えられる。
全項目を保存することを勧める表ではなく，処理されるものと，その確認資料を特定するための表である。

対象確認すること確認資料の例元の資料・データ保管主体，保管先，利用目的，参照できる範囲元サービスの設定，資料の分類，契約問い合わせと認証検索語や条件に含まれる情報，接続するアカウント，権限接続設定，権限表，要求記録取得データとキャッシュ取得する範囲，一時保存先，保持・削除の条件機能別の仕様，設定，提供者の回答AIの入力・出力どのモデル・機能が何を処理するか，出力の保存先利用プラン，機能別のデータ説明，処理記録ログと派生情報本文・検索語・識別情報等が記録されるか，閲覧者，保持期間ログ設定，監査資料，保存・削除の説明

例えば，原本は自社管理のストレージに残っていても，分析結果を別サービスの報告書へ書き出す工程があれば，その出力先まで確認する。
資料の本文だけでなく，問い合わせ条件，ファイル名又はログに秘密情報が含まれないかも検討する。

「保存場所を選べる」という機能についても，選択の対象が原データ，処理，キャッシュ，ログ又はサポート時の取扱いのどこまで及ぶかを尋ねたい。
不明な部分を，事業者名やリージョン名だけで補わない。

第４　契約・個人情報・秘密情報の確認

個人情報保護委員会の令和５年６月２日付け注意喚起は，個人情報取扱事業者に対し，個人情報を含むプロンプトの入力が利用目的の達成に必要な範囲内であることを十分に確認すること，本人の同意なく個人データを含むプロンプトを入力する場合には，提供事業者がその個人データを機械学習に利用しないこと等を十分に確認することを求めている。
もっとも，この注意喚起だけで，個別のクラウド連携における委託，第三者提供又は国外処理の評価が決まるわけではない。

契約の確認では，元のストレージ，接続機能，分析基盤，AI機能及び出力先について，適用される契約・機能・アカウントを対応させたい。

（続きを読む...）データを動かさないAI・クラウド連携は安全か―ゼロコピー，キャッシュ及び外部処理の確認事項（AI作成）

目次

第１　この研究から何が分かるか第２　MITの仮想島実験の仕組み１　具体的な仕事を与えずに活動させる２　世界と会話はリセットしても記録は残る３　公開コードと記録で何を確かめられるか第３　AIは何を学び，何を間違えたか１　記憶に残した手順が後の課題に影響する２　誤った記憶は行動の選択肢を狭める３　実験結果と理由の説明は別に確かめる第４　動画投稿者の２体実験との違い第５　法律事務所のAI利用へどう応用するか１　結論だけでなく，確認できる根拠を引き継ぐ２　誤りを訂正したら，それを使った成果物も確認する３　AI同士の一致を独立した裏付けと扱わない４　自由な探索の範囲と，本番の権限を分ける第６　出典
第１　この研究から何が分かるか

仕事を与えられていないAIが，仮想の島で積み木を積み，ボウリングに似た遊びを始めたという論文がarXivで公開された。
MITの研究者による「Is this machine playing?」である。
本記事は，令和８年１１月１日に確認した原論文と研究側の公開資料を基に，実験で示されたことと，そこから法律事務所のAI利用について考えられることを分けて説明する。

注目したいのは，AIが人間と同じ楽しさを感じたかという問題より，経験を記録し，次の活動へ持ち越す仕組みである。
基盤となるモデルを再訓練しなくても，記憶ファイルに書かれた知識を利用して，後の課題でできることが変わったと報告されている。
一方，誤った知識も記録され，後の行動を妨げる場合があったとも報告されている。

研究が扱うのは，特定の仮想世界におけるエージェントの行動である。
法律調査，判例の引用精度又は契約書作成の能力が改善したことを直接検証した研究ではなく，AIの意識や感情を証明したものでもない。

第２　MITの仮想島実験の仕組み
１　具体的な仕事を与えずに活動させる

主実験では，１３体のエージェントを同じ島に集めたのではなく，１体ずつ別の世界で３０時間活動させた。
主実験はClaude Code（Claude Opus 4.7）を用いた。
同じ設定のCodex（GPT-5.5）とKimi Code（Kimi K2.6）各５体では，取り組んだ活動の幅が大幅に狭かったと報告されている（付録C.5）。
島には積み木，岩，輪，高さの異なる地形があり，エージェントは移動，ジャンプ，物を拾う，置く，投げるといった操作を行う。
主実験の観察情報は画像ではなく，物の位置や形状などを表す文字情報である（原論文第２節）。

ここで「仕事を与えない」とは，特定の競技，得点又は達成課題を指示しないという意味である。
指示が全くないわけではなく，好奇心を持って探索する人格設定や，停止したときに活動の継続を促す仕組みが用意されている。
論文には人格設定を外して指示を簡略化した追加実験もあり，その分析では，取り組んだ活動の種類に明確な差を観察しなかったと報告されている（付録C.4）。

２　世界と会話はリセットしても記録は残る

実験では，１時間ごとに世界とエージェントのセッションをリセットする一方，作業用のファイルは残す。
エージェントは，何が起きたかを記録する出来事の記憶と，知識や手順を整理する記憶を利用する。
次のセッションでは，それらの記録を読み，前の経験を後の行動へつなぐ（原論文第２．３節，研究公式サイト）。

したがって，モデルの重みを更新する再訓練と，外部に残した記録を読み直して行動を変えることは区別する必要がある。
「モデルを再訓練していない」ことを，「エージェントは何も学んでいない」と言い換えると，この研究の主題を捉え損なう。

３　公開コードと記録で何を確かめられるか

研究側は，仮想世界を動かすClawbloxのコードと，補足データを公開している。
補足データの説明では，世界の状態記録，エージェントの操作・応答，記憶ファイルが区別されている。
「AIが成功したと書いたこと」と，「世界の中で何が起きたか」を照合するための資料が用意されている点も重要である。

（続きを読む...）AIは遊びから学ぶのか―MITの仮想島実験と「誤った記憶」の問題（AI作成）

目次

第１　Talkieとは何か第２　開発者の説明と紹介者の実験を分ける第３　「１９３０年まで」は完全な遮断を意味しない第４　回答から分かること，分からないこと第５　法律実務では「何年まで学習したか」の先を確認する第６　原典照合を仕事の手順にする第７　関連する確認方法
第１　Talkieとは何か

Talkieは，開発者が１９３０年末までの資料を学習対象としたと説明する言語モデルである。
「昔の人のように話して」と現代のAIに指示する方法とは異なり，学習資料の年代を制限する研究として紹介されている。
ただし，その年代より後の知識を完全に排除できたという意味ではない。開発者の紹介文

本記事は２０２６年１１月１日を確認基準日とし，開発者の説明と，AI深層部【ゆっくり解説】の紹介動画を区別して読む。
注目したいのは未来予測の当たり外れだけでなく，回答の根拠となった資料と時点をどう確かめるかという問題である。紹介動画

第２　開発者の説明と紹介者の実験を分ける

開発者の紹介文は，モデルの学習方法や評価，年代制限の難しさを説明する資料である。
一方，紹介動画には，動画制作者がTalkieに質問した結果として紹介する回答も含まれる。
開発者が公表した実験と，動画制作者が試したと述べる実験は，同じものとして引用しない。

動画では，未来の生活，思考する機械，自分が機械だと告げられた場合の反応などを取り上げている。
これらは，まず「動画でそのような応答が紹介されている」という範囲で読む。
本記事の作成時には字幕と説明欄を確認したが，実験を独自に再現したわけではなく，画面内の英語の全対話や全設定も確認していない。紹介動画

海外メディアThe Decoderも，２０２６年の世界像や第二次世界大戦の可能性についてのTalkieの回答を紹介している。
同記事からは同媒体独自の試行かどうかまでは確認できないため，独立した再現結果として数えない。The Decoderの記事

第３　「１９３０年まで」は完全な遮断を意味しない

開発者自身，年代より後の情報の混入を課題として挙げている。
古い資料を集めても，後世の情報を含む資料が紛れ込むことがある。
開発者は，年代に合わない文書を判定する分類器で選別したものの完全ではなかったと述べ，公開モデルの１３Ｂ版についても，第二次世界大戦や直後の国際秩序に関する一部の細部を知っていると説明している。開発者の紹介文の「Temporal leakage」

また，公開されている基礎モデルと，対話の指示に応じるよう調整されたモデルを区別する必要がある。
開発者は，後段の調整では歴史資料から作った指示と応答の組を使った上で，現代のAIによる評価や，現代のAIとTalkieとの合成対話も利用したと説明している。
学習資料の年代だけを見て，回答の語り方や振る舞いまで当時の資料だけから生じたと考えるのは早計である。開発者の紹介文・公開モデルの説明

開発者は，画像から文字を読み取る現代のAIによって，原画像にない現代的な情報が入り込む問題にも言及する。
これは当該開発での報告であり，法律文書のOCR全般について誤りの頻度を測定した研究結果ではない。
もっとも，読み取り結果が自然な文章であるほど，原画像との照合を省いてよいとはいえないという実務上の注意につながる。開発者の紹介文

第４　回答から分かること，分からないこと

現代とは異なる答えが出たとしても，それだけで当時の社会全体の意識を再現したとはいえない。
収集された資料の種類や偏り，読み取りの精度，モデルの調整，質問の表現が結果に関係し得るからである。
開発者のリポジトリも，古い資料で学んだモデルと現代の資料で学んだモデルの違いを，年代だけに帰せないことを注意点としている。公式リポジトリ

（続きを読む...）１９３０年までの資料で学んだAI「Talkie」とは―知識の時点・情報混入・法律実務での原典確認（AI作成）

目次

第１　結論と，この記事が確認する範囲第２　動画の仕事術と，製品の情報管理を分ける第３　学習への非利用の対象データを読む第４　Google連携への同意と，外部AIへの送信を分ける第５　保存期間，連携解除，削除及び国外処理を分ける第６　導入前の質問と，小さく試す順序第７　根拠資料と，確認できていないこと
第１　結論と，この記事が確認する範囲

satto workspaceの導入を検討するときは，便利さの説明と，どの情報にどの取扱条件が適用されるかを分けて確認したい。
特に，公式プライバシーポリシー第５項⑴の「学習（トレーニング）への非利用」はGoogleユーザーデータを対象とする記載であり，その一文から，全ての入力ファイル，会話及び生成物について同じ条件が保証されると広げることはできない。
連携の解除，取得済みデータの削除及び契約終了時の処理も，別々の確認事項である。

本記事は，令和８年１１月１日に確認した法人向けsatto workspaceのプライバシーポリシーと，そこから案内される公式資料を読むための整理である。
個別の契約書，DPA，管理画面又は実際のデータ処理を監査したものではない。
後記の質問例と利用範囲の区分は，当ブログの実務上の提案であり，提供者が公表した機能又は法律上一律に義務付けられた様式ではない。

第２　動画の仕事術と，製品の情報管理を分ける

検討のきっかけは，東洋経済オンラインの平岡拓氏への取材動画である。
同サイトの掲載ページによれば，公開は令和８年１０月２日であり，動画内のデータは同年９月３日の収録時点のものである。
動画は仕事の進め方を紹介する取材であり，製品の契約条件を網羅的に説明する資料ではない。

動画の８分頃には，人が休んでいる間にもAIに作業をさせるという趣旨の仕事術が語られる。
１８分４１秒頃以降のリーンキャンバスのレビューの場面では，本人が戦略系のタスクにはClaude Codeを使っていると説明しており，この場面をsatto workspace固有の機能の実演として説明するのは適切でない。
個人の体験談を，法律事務所における生産性又は法的な安全性を実証した結果へ置き換えることも避けたい。
動画内容の確認は公開の自動字幕を基にしており，映像全編の直接視聴又は実機での再現試験を行ったものではない。

したがって，動画で関心を持った後は，実際に利用する製品の資料へ移り，入力する情報と許可する操作を決める順序が考えられる。
夜間作業の依頼内容，停止条件及び翌朝の確認については，法律事務所のAIエージェント業務設計も参照されたい。

第３　学習への非利用の対象データを読む

公式ポリシー第１項は，対象を法人向けsatto workspaceに限定し，個人向けのsatto memo及びsatto shortcutとはデータ管理体系等が異なると説明している。
製品名が似ていても，別サービスの規約をそのまま適用しないことが出発点になる。

第２項は，登録情報や操作ログ等と，Google API連携で取得するGoogleユーザーデータを分けている。
第５項⑴の学習への非利用は後者についての記載である。
この限定を残して読むとともに，手動でアップロードする資料，会話，出力及び派生データについては，適用される契約・説明を別に確認することが望ましい。
ここから「その他のデータは必ず学習に使われる」という逆の結論が出るわけでもない。

第３項にはGoogleユーザーデータの利用目的として機能提供等と品質向上が挙げられている。
品質向上という目的の記載と，モデルの学習に使うかという処理方法の記載を，同じ言葉として扱わないことが大切である。
提供者への質問では，「改善に使うか」だけでなく，対象データ，具体的処理，人的閲覧，保存期間及び再委託先を分けると確認しやすい。

第４　Google連携への同意と，外部AIへの送信を分ける

第２項２．２は，利用者の明示的な同意によるGoogle連携と，許可された範囲の取得を説明している。

（続きを読む...）satto workspaceの情報管理を確認する―Google連携データ，学習利用，保存と削除（AI作成）

目次

第１　貸借対照表の数字と契約上の負担を分ける第２　MetaのHyperionに関する開示１　出資，施設の利用及び保証は別の関係である２　連結していない理由も会社自身の説明として読む第３　残価保証は誰に何を支払う約束か１　開示された発動条件を見る２　サービス利用者向けの保証と区別する第４　単四半期の設備投資と累計の資金収支を分ける第５　AIサービスの導入企業が確認する事項第６　関連する記事と一次資料１　関連する記事２　一次資料
第１　貸借対照表の数字と契約上の負担を分ける

AI向けデータセンターへの投資を見るときは，貸借対照表に計上された借入金だけでなく，別の事業体への出資，リース契約，将来の資金拠出及び保証を分けて確認することが有用である。
本記事では，MetaがHyperionデータセンターについて公表した資料を例に，こうした確認の仕方を説明する。

ここでいうSPVは，特定の資産・事業を扱うための事業体を指す呼称として用いる。
事業体を別に設けたこと，その事業体を連結していないこと，親会社に契約上の負担が残ることは，それぞれ別に確認する事項である。
「オフバランス」という言葉だけで，将来の支払がないことや，開示がされていないことを意味すると読むのは適切ではない。

以下の取引構造は２０２５年１０月の発表と２０２６年３月３１日を期末とするForm 10-Qの注記５に基づく。
資金収支は２０２６年１０月２１日公表の第３四半期決算資料を用い，資料の基準日を混ぜない。

なお，Metaは２０２６年１０月２２日に，同年９月３０日を期末とするForm 10-Qを提出している。
同報告書の注記５は，Hyperionのあるルイジアナの事業体にテキサスの事業体を加え，２事業体合計の最大エクスポージャーを６８，４０４百万米ドル（うち残価保証の最大額は４１，４９３百万米ドル）と記載している。
本記事の第２及び第３は，ルイジアナの事業体の条件を説明するため，第１四半期の注記を用いる。

第２　MetaのHyperionに関する開示
１　出資，施設の利用及び保証は別の関係である

Metaの２０２５年１０月の発表によれば，Hyperionの開発・所有に関する合弁事業は，Blue Owlが運用するファンド側が８０％，Metaが２０％を保有する構成であり，建物及び長期の電力・冷却・接続設備の開発費用の総額約２７０億米ドルを，両者が持分割合に応じて拠出することを約束した。
Metaは施設を利用するオペレーティング・リースを締結し，リースの不更新又は終了の後に一定の条件が満たされた場合に，その時点の施設の価値に基づく上限付きの現金を合弁事業へ支払う残価保証も提供したと説明した。
出資比率だけで，施設の利用条件や保証の内容まで説明できるわけではない。

２０２６年第１四半期のForm 10-Q注記５は，リースの開始を２０２９年とし，当初期間を４年，更新オプションを含めた期間を最長２０年と記載している。
この記載は，資料に示された契約条件の説明であり，施設が既にその全期間稼働したことを示すものではない。

２　連結していない理由も会社自身の説明として読む

同じ注記でMetaは，当該事業体の経済的成果に最も重要な影響を与える活動を指図する権限を持たないため，変動持分事業体（VIE）の主たる受益者ではなく，連結していないと説明している。
また，投資の帳簿価額とは別に，投資，リースの約束，将来の資金拠出及び残価保証を含む最大エクスポージャーを開示している。

ここでは，連結の有無と，別途開示された契約上の負担の双方を読む必要がある。
最大エクスポージャーを，そのまま損失の発生見込額や貸借対照表の借入金と同一視することも適切ではない。
これらは会社が示した会計処理と開示内容の紹介であり，本記事がその会計処理の適否を独自に監査したという趣旨ではない。

第３　残価保証は誰に何を支払う約束か
１　開示された発動条件を見る

２０２５年１０月の発表では，残価保証は施設運営開始後の最初の１６年間を対象とし，リースの不更新又は終了の後に所定の条件が満たされた場合に，その時点の施設の価値に基づいて上限付きの現金を合弁事業へ支払う仕組みとして説明されている。
２０２６年第１四半期の注記５は，Metaがリースの終了又は不更新を決め，かつ他の条件も満たされた場合，最大の支払額はその時点の公正価値と当該物件の保証基準額との差額に等しくなると記載している。
「保証がある」という一言にまとめず，支払先，対象，発動条件，対象期間及び金額の上限を確認することが重要である。

（続きを読む...）AI企業のオフバランス取引とは―Metaの開示で読むSPV・リース・残価保証（AI作成）

目次

第１　結論第２　CPU使用率１００％の意味１　短時間の上昇と継続する上昇を分ける２　PC全体とプロセス別の値を分ける第３　最初に確認する項目１　時刻と継続時間２　上位プロセスと子プロセス３　メモリ，ディスク及びGPU第４　自動起動と同時実行を見直す１　スタートアップアプリを確認する２　期限業務に必要な軽いアプリを先に開く３　作業を続けながら入力とクリックの応答の改善を図る場合の調整と限界４　ウイルスバスターのCPU負荷を保護を維持して確認する５　不要なGit確認と記録の書込みを減らす第５　最大のプロセッサの状態を９５％にする方法１　９５％の意味２　現行値を記録して変更する３　機種によって効果が異なる第６　変更前後を比較する第７　CPU以外を調べる場合第８　確認用チェックリスト第９　関連記事第１０　出典・参考資料
第１　結論

Windows 11でCPU使用率が１００％近くまで上がると，文字入力，ウィンドウの切替え及び軽いアプリの起動まで遅くなることがある。
本記事は，CPU使用率の読み方，重い処理と自動起動の見直し，作業を続けながら入力応答の改善を図る場合の注意点，ウイルスバスターの保護を維持した確認及び「最大のプロセッサの状態」を９５％に設定する場合の意味と注意点を説明する。

CPU使用率１００％は，その測定ツールと区間における値が上限付近にあることを示すにとどまり，CPUの物理的な全能力を使い切ったこと，又は故障・フリーズの原因を確定する表示ではない。
短い上昇と継続する上昇，PC全体の値と個別プロセスの値，CPU・メモリ・ディスク・GPUの負荷を分ける必要がある。

利用者が意図して動かしている重い処理が競合している場合，軽いアプリをいつでも開きやすい状態にする第一候補は，同時実行数を減らし，不要なスタートアップアプリを見直し，一度に多数の処理を再開しないことである。
原因不明の場合は，先に上位プロセスと他の資源を確認する。

発熱又は高い性能状態での動作が関与する疑いがあり，影響を測定しながら試す場合には，最大のプロセッサの状態を９５％にする方法もある。
ただし，一律に推奨されるフリーズ対策ではなく，CPUの５％を軽いアプリ専用に取り置く設定でもない。
特定のアプリではなく，使用中の電源プランについて，プロセッサの最大性能状態を最大性能の９５％までとする設定である。
軽いアプリを含む全体に作用し，実際の効果はCPU，ファームウェア及び電源プランによって異なることがあるため，現行値を記録し，一つの変更として比較する必要がある。

第２　CPU使用率１００％の意味
１　短時間の上昇と継続する上昇を分ける

アプリの起動，Windows Update，圧縮・展開，ウイルス検査，検索索引，PDF変換又はビルドの開始時には，CPU使用率が短時間だけ大きく上がることがある。
短い上昇だけで異常とはいえない。

一方，CPU使用率が長く１００％近くに張り付き，その間に文字入力，マウス操作，ウィンドウの切替え又は軽いアプリの起動まで遅くなる場合は，CPUの飽和が応答低下に関与している可能性が高くなる。
一律の秒数・分数の基準はなく，同時発生と再現性を確認する。
高いCPU使用率は原因である場合も，他の問題の結果である場合もあるため，発生時刻と継続時間を記録し，平常時と比較する。

２　PC全体とプロセス別の値を分ける

タスクマネージャー又はパフォーマンスモニターでは，PC全体のCPU使用率と，プロセス別のCPU使用率を分けて見る。
Microsoftの性能カウンター資料によれば，Processor(_Total)の% Processor Timeは全プロセッサの平均使用率であり，範囲は０から１００である。
これに対し，パフォーマンスモニターのProcess又はProcess V2の% Processor Time等，プロセス内の全スレッドの使用率を合算するカウンターでは，複数のプロセッサを使うプロセスが１００％を超える表示になり得る。
この説明を，タスクマネージャーのプロセス欄へそのまま当てはめてはならない。

タスクマネージャー内の値と，パフォーマンスモニターの特定カウンターは分けて読む。
標本化時刻，丸め，System及び割込み等のため，単純な足し算と一致しない場合もある。
総CPUが高いのか，特定プロセス又はその子プロセスが高いのかを確認する。

第３　最初に確認する項目
１　時刻と継続時間

CPU使用率が上がった時刻，何分続いたか，入力遅延が始まった時刻及び自然に戻ったかを記録する。

（続きを読む...）Windows 11でCPU使用率が１００％になる原因の切分けと対策―軽いアプリの応答，自動起動及び最大のプロセッサの状態（AI作成）

目次

第１　結論第２　最初に四つの停止を分ける１　会議アプリ又はブラウザーだけが止まった場合２　映像・音声又は通信だけが止まった場合３　表示系だけが止まった場合４　Windows全体が止まった場合第３　オンラインセミナー中にPCで生じる処理１　映像の受信，復号及び描画２　カメラ，マイク，画面共有及び録画３　ブラウザー，クラウド同期及び常駐処理第４　オンラインセミナー中のAI操作は特に危険か１　ブラウザーで質問するだけの場合２　ローカル処理を伴うAIエージェントを動かす場合３　同時利用は原因ではなく負荷を重ねる条件である第５　視聴前に行う再発防止１　事前テストと再起動の時期２　不要な処理を減らす３　代替端末と連絡手段を用意する４　電源，冷却及びネットワークを確認する第６　フリーズしたときの初動１　時刻と停止範囲を記録する２　会議の継続を優先する３　外部操作の成否を分ける第７　再起動後に調べる記録１　Event 41と予期しない終了の時刻２　性能ログの最後のサンプル３　クラッシュダンプと手動取得４　通信と動的ポート第８　安全な再現試験第９　確認用チェックリスト第１０　本記事の限界第１１　関連記事第１２　出典・参考資料
第１　結論

オンラインセミナー又はWeb会議の視聴中にWindows 11が固まった場合は，①会議アプリ又はブラウザーだけの停止，②映像・音声又は通信だけの停止，③表示系の停止，④Windows全体のハードハングを分けて確認する必要がある。
同じ「画面が固まった」という見え方でも，必要な対処と残る記録が異なるからである。

Zoom又はTeamsの映像・音声処理に加え，AI，クラウド同期，大量コピー，PDF変換その他の処理を同じPCで同時に動かせば，CPU，GPU，メモリ，ディスク及びネットワークの負荷は重なり得る。
もっとも，オンラインセミナー中にAIを操作することが一般に特に危険である，又はAIを併用しただけでWindows全体がフリーズするとまではいえない。

ブラウザーでAIの回答を読む程度と，AIエージェントに大量のファイル検索，PDF・画像変換，ビルド，テスト又は複数の並列処理を実行させる場合とでは，手元のPCに生じる負荷が異なる。
重要なセミナー又はWeb会議では，視聴に不要な重いローカル処理を止め，必要ならAI操作を別端末へ分けるのが安全である。

第２　最初に四つの停止を分ける
１　会議アプリ又はブラウザーだけが止まった場合

Zoom，Teams又はブラウザーのタブだけが応答せず，マウス，タスクバー及び他のアプリを操作できる場合は，PC全体のフリーズとは区別する。
会議アプリの終了前に，発生時刻，視聴していた会議，音声の継続，エラー表示及び他のアプリを操作できたかを記録する。

２　映像・音声又は通信だけが止まった場合

映像が止まっても音声が続く場合，音声だけが途切れる場合，又は会議から切断されてもWindowsを操作できる場合は，通信品質，アプリ側の状態，カメラ・マイク等の機器及び映像処理を分けて確認する。
Microsoft Teamsには，会議中のラウンドトリップ時間，パケット損失，ビットレート，フレームレート及び端末の処理状況等を確認できる「通話の正常性」機能がある。
表示項目と利用可否は，クライアント，端末及び会議の種類によって異なり得る。

司法研修所事務局が第76期司法修習生向けに作成した令和4年10月の「修習におけるオンライン利用の手引」は，画面の停止又は通信の途切れについて，ネットワークを利用する他のアプリの終了や，電波状況の良い部屋への移動を案内している。
これは通信品質の初動であり，Windows全体のハードハングの原因をネットワークに限定するものではない。

３　表示系だけが止まった場合

画面が黒くなる，点滅する，又は描画が更新されない一方で，音声又はネットワーク応答が続く場合は，GPU，ディスプレイドライバー又は表示経路の停止を検討する。
画面共有，背景効果，多数の参加者映像及び高解像度表示は，映像の処理量を増やし得るが，一回の同時発生だけで表示系が原因とは断定しない。

４　Windows全体が止まった場合

一定時間待っても入力，画面及び通常の終了操作等の複数の系統が応答せず，アプリ単体の停止又は表示停止だけでは説明しにくい場合は，Windows全体のハードハングを疑う。
音声又はネットワークの状態は補助所見であり，すべての項目が止まることを必須条件としない。
強制電源断は未保存データの消失又はファイル破損を生じ得るため，通常の終了手段がない場合の最終手段とする。

可能であれば，別端末で発生時刻と画面を記録し，電源を切る前にCaps Lock等への反応と音声を確認する。
既に安全に設定された監視又は接続方法がある場合に限り，別端末からの既知の応答も補助所見とする。
Microsoftは，Caps Lockキーのランプが変化しない場合を応答停止の確認例として挙げているが，ワイヤレス機器又はソフトウェア制御の表示灯等では判断できないことがあるため，この確認だけで原因は確定しない。

第３　オンラインセミナー中にPCで生じる処理
１　映像の受信，復号及び描画

（続きを読む...）オンラインセミナー・Web会議中にWindows 11がフリーズする原因と対策－Zoom・TeamsとAIの同時利用（AI作成）

目次

第１　結論―約１６０点は有力な参考値であるが，公式の受験結果ではない第２　Legalscapeが公表した試験方法と結果第３　法務省が公表した人間の得点分布第４　人間の最高点と直接比較できない理由１　３回平均と１回の受験結果は異なる２　公開問題を解く条件は統制試験と同じではない３　ベンダーの自己評価と第三者評価を区別する第５　短答式約１６０点から分かることと分からないこと第６　法律事務所で導入前に確認する事項第７　関連記事第８　出典と確認状況
第１　結論―約１６０点は有力な参考値であるが，公式の受験結果ではない

Legalscapeは，令和６年司法試験の短答式試験を同社の法務AIで解かせ，３回の平均得点が約１６０点であったと令和７年５月２３日に発表した。
法務省が公表した令和６年司法試験短答式試験の人間の最高点は１６６点，受験者全体の平均点は１１２．１点，合格に必要な成績は合計９３点以上（ほかに科目別の最低点がある。）であった。

約１６０点は１７５点満点の約９１％に当たり，同じ配点で見れば高い数値である。
しかし，これはLegalscapeが開発中のシステムについて行った事業者自身の評価であり，法務省がAIを受験者として採点し，合格又は順位を認定したものではない。
人間の最高点１６６点と並べることはできても，「人間の受験生の得点分布に当てはめれば全国何位相当であった」などと順位へ置き換えることはできない。

第２　Legalscapeが公表した試験方法と結果

Legalscapeの公表資料は，令和６年司法試験の短答式試験を対象とし，Legalscape，ChatGPT，Gemini及びPerplexityに各問題を３回ずつ回答させたと説明している。
公表された３回の平均得点は，Legalscapeが約１６０点，Geminiが約１１８点，ChatGPTが約１１５点，Perplexityが約７３点であった。

同資料は，各設問で満点を得た割合の３回平均についても，Legalscapeが約９０％，Gemini及びChatGPTが各約６３％，Perplexityが約３７％であったとする。
これらは同社の公表値であり，本記事で全回答ログを取得して再採点した結果ではない。

評価対象となったLegalscapeは開発中のバージョンであった。
したがって，この数値を，現在利用できる製品のあらゆる回答が約９０％正しいという保証や，契約すれば法律実務の９割を自動化できるという意味に読み替えてはならない。

第３　法務省が公表した人間の得点分布

法務省の令和６年司法試験（短答式試験）の結果によれば，短答式試験は１７５点満点であり，合格に必要な成績は，各科目で満点の４０％点（憲法２０点，民法３０点，刑法２０点）以上を得た上で合計９３点以上であった。
最高点は１６６点，最低点は３２点，受験者全体の平均点は１１２．１点，短答式試験の合格に必要な成績を得た者の平均点は１２０．３点であった。

Legalscapeの約１６０点を１７５点満点で単純計算すると約９１．４％であり，人間の最高点１６６点が１７５点満点に占める約９４．９％より約３．４ポイント低い。
受験者全体の平均点との差は約４７．９点である。
ただし，Legalscapeの得点は「約１６０点」という丸められた３回平均であるため，小数点以下まで正確な差を示す計算ではない。

法務省の資料が直接示すのは，人間の受験者についての得点分布である。
AIの実行環境，回答生成方法又は再現性を法務省が確認した資料ではない。
AI側の条件はLegalscapeの公表資料，人間側の得点分布は法務省資料というように，根拠の作成主体を分けて読む必要がある。

第４　人間の最高点と直接比較できない理由
１　３回平均と１回の受験結果は異なる

人間の最高点１６６点は，受験者が本試験で得た１回の得点である。
他方，Legalscapeの約１６０点は３回実行した平均値である。
平均値だけでは，各回の得点のばらつき，毎回同じ設問を落としたのか，実行ごとに正誤が入れ替わったのかを判断できない。

２　公開問題を解く条件は統制試験と同じではない

令和６年司法試験の問題と正解は公表されている。

（続きを読む...）LegalscapeのAIは司法試験短答式で約１６０点だったのか―令和６年の人間最高１６６点との比較と限界（AI作成）

目次

第１　結論第２　Event 41が示すことと示さないこと１　正常終了を経ない再起動を示すこと２　記録時刻を停止開始時刻と取り違えないこと第３　Event 41の主要フィールド１　BugcheckCode２　PowerButtonTimestamp３　BugcheckCodeとPowerButtonTimestampがともに0の場合第４　併せて確認するイベント１　正常終了を示す記録２　異常終了を示す記録３　Windows Error Reportingの古い記録を現在の障害と取り違えないこと第５　強制終了前後の時系列を作る方法１　五つの時刻を分けること２　最後のログが原因を示すとは限らないこと第６　実測例から分かること第７　再発防止に使う場合の注意第８　関連記事第９　出典・参考資料
第１　結論

Kernel-Power Event 41は，Windowsが正常なシャットダウンを完了しないまま再起動したことを示す記録である。
Event 41があるだけでは，電源，メモリ，GPU，ドライバー又は特定のアプリのどれが原因であったかは確定できない。

原因を絞るときは，Event 41の記録時刻だけを見るのではなく，①最後に正常に操作できた時刻，②性能ログ又はアプリログが途切れた時刻，③電源ボタンを長押しした時刻，④Windowsが再起動した時刻，⑤Event 41が記録された時刻を分ける必要がある。
BugcheckCode，PowerButtonTimestamp，EventLog 6008，WER-SystemErrorReporting 1001，volmgr 46，ダンプの有無及び発生直前の性能ログを同じ時系列に並べるのが基本である。

第２　Event 41が示すことと示さないこと
１　正常終了を経ない再起動を示すこと

Microsoftの説明によれば，Event 41は，Windowsが完全なシャットダウンを経ずに再起動したことを示す。
フリーズしたPCを電源ボタンで強制終了した場合，突然電源が失われた場合，又はブルースクリーン後に自動再起動した場合のいずれでも記録され得る。

したがって，Event 41は「異常終了又は異常再起動があった」という入口の記録であり，原因名そのものではない。
イベントビューアーに「重大」と表示されることも，特定部品の故障を確定する意味ではない。

２　記録時刻を停止開始時刻と取り違えないこと

Event 41は，異常終了後にWindowsが起動した際に記録される。
そのため，Event 41の時刻は，画面又は入力が固まり始めた時刻より後になることがある。

フリーズ開始から強制終了まで数分間あった場合，Event 41の時刻だけを検索条件にすると，原因候補となる直前の処理を見落としやすい。
最後に正常だった時刻から再起動完了までを一つの調査区間とし，その区間のApplicationログ，Systemログ，性能ログ，信頼性履歴及びアプリの作業記録を照合する。

第３　Event 41の主要フィールド
１　BugcheckCode

BugcheckCodeが0以外である場合は，WindowsがStopエラーを検出した可能性が高くなる。
MicrosoftによればEvent 41のBugcheckCodeは十進数で記録されるため，ブルースクリーンの一般的な16進数コードと照合するときは表記を変換する。

もっとも，BugcheckCodeだけで原因となったドライバー又はハードウェアが直ちに分かるとは限らない。
WER-SystemErrorReporting 1001（イベントビューアーのソース欄ではBugCheckと表示される場合がある。），ダンプファイル及びデバッガーの解析結果を合わせて確認する。

２　PowerButtonTimestamp

Microsoftは，電源ボタンを長押しして再起動した場合，Event 41のPowerButtonTimestampが0以外になる例を示している。
この値は，電源ボタンによる強制終了を検討する重要な手掛かりとなる。

ただし，PowerButtonTimestampが0であることは，電源ボタンを操作していないことの完全な証明ではない。
PCが完全に応答せず，Windowsが情報をディスクへ書けなかった場合又は急激に電源が失われた場合は，値が残らないことがある。

３　BugcheckCodeとPowerButtonTimestampがともに0の場合

両方が0の場合は，電源断，ハードハング，Stopエラー情報の書込み失敗その他の可能性が残る。

（続きを読む...）Kernel-Power Event 41とは―BugcheckCode，PowerButtonTimestamp及び強制終了時刻の読み方（AI作成）

目次

第１　結論第２　三つの選択肢の違い１　Windows に決定を任せる２　省電力３　高パフォーマンス第３　アプリごとにGPUを指定する手順１　対象アプリを追加する２　GPUの優先設定を保存する３　変更後に確認する第４　フリーズ調査での使い方第５　アプリ更新後に再確認する理由第６　遠隔操作との関係第７　記録しておく項目第８　設定変更で解決しない場合第８の２　アプリのGPU指定とモニターの接続先は別である第９　関連記事第１０　出典・参考資料
第１　結論

複数のGPUを搭載するWindows 11のパソコンでは，「設定」→「システム」→「ディスプレイ」→「グラフィック」から，アプリごとに使用するGPUの優先設定を選べる。
Microsoftの案内が挙げる選択肢は，Windowsに選択を任せる「Windows に決定を任せる (省電力)」，消費電力の小さいGPUを優先する「省電力」，性能の高いGPUを優先する「高パフォーマンス」である。
Windowsの版により「Windows での自動決定 (省電力)」等と表示され，他の項目が表示されることもある。

この設定は，複数のGPUを搭載するパソコンで，特定アプリの描画先を比較するために役立つ。
ただし，GPUを指定すればフリーズが直るとは限らない。
Windows全体の停止には，表示ドライバー，GPU，電源，メモリ，ストレージ，同期処理その他の原因もあり，アプリ別GPU設定は原因を一つずつ切り分けるための可逆的な比較手段として使うのが安全である。

第２　三つの選択肢の違い
１　Windows に決定を任せる

既定状態では，Windowsがアプリに使用させるGPUを決める。
特定のGPUを優先する必要がない場合，又は手動指定によって症状が改善するか分からない場合は，まずこの状態を基準として記録する。

２　省電力

MicrosoftのDXGIの定義（設定画面の説明ではなくAPIの定義である。）では，省電力側の選好は，統合GPU等の消費電力が小さいGPUを優先する考え方である。
発熱又は消費電力を抑えたい場合の候補となるが，「省電力」という名称だけで安定性が高いと決まるわけではない。

３　高パフォーマンス

高パフォーマンス側の選好は，外付けGPU又はディスクリートGPU等の性能が高いGPUを優先する考え方である。
描画負荷の高いアプリでは性能上の利点があり得るが，消費電力，発熱及び使用するドライバー経路も変わり得るため，フリーズ対策として一律に選ぶ設定ではない。

第３　アプリごとにGPUを指定する手順
１　対象アプリを追加する

①「設定」を開く。
②「システム」→「ディスプレイ」→「グラフィック」を開く。
③対象アプリが一覧にある場合はそのアプリを選ぶ。
④一覧にない場合は，デスクトップアプリ又はMicrosoft Storeアプリ等の区分を確認し，対象アプリを追加する。
⑤似た名前の実行ファイルが複数ある場合は，実際に起動しているファイルの場所と一致するかを確認する。

２　GPUの優先設定を保存する

対象アプリの「オプション」を開き，「Windows に決定を任せる」，「省電力」又は「高パフォーマンス」を選んで保存する。
Microsoftの案内では，変更後に対象アプリを再起動する手順となっている。
設定変更前に編集中のデータを保存し，そのアプリだけを終了して再起動する。

３　変更後に確認する

（続きを読む...）Windows 11でアプリごとにGPUを指定する方法―省電力・高パフォーマンスの違いとフリーズ対策（AI作成）

目次

第１　結論第２　エラーが示していること１　権限プロファイルとdefault_permissions２　[permissions.network]と書いた場合第３　config.tomlの場所第４　直し方１　組込みのプロファイルを既定にする２　作ったプロファイルを既定にする３　権限プロファイルを使わず従来の設定に戻す第５　直した後に確かめること１　起動と実際の権限２　プロジェクトの設定が反映されないという報告第６　組織が設定を管理している場合第７　法律事務所で設定を変えるときの注意第８　関連記事第９　出典
第１　結論

Codexを起動しようとしたときに，「config defines [permissions] profiles but does not set default_permissions」と表示されて先へ進めない場合は，設定ファイルであるconfig.tomlの記載を確認する。
この表示は，config.tomlに権限プロファイル（[permissions.名前]で始まる表）が書かれているのに，どのプロファイルを既定とするかを指定するdefault_permissionsが書かれていないことを示すものと考えられる。

直し方としては，次の二つが考えられる。
①config.tomlの最初の表の見出しより前に，default_permissions = ":workspace" のように，既定とするプロファイルを指定する１行を加える。
②権限プロファイルを使わないのであれば，[permissions.名前]で始まる表を削除し，従来のsandbox_modeによる設定に戻す。
もっとも，[permissions.network]のように，プロファイルとして書いたつもりのない表がある場合は，その表が「network」という名前のプロファイルとして読まれ，ネットワークの設定としては働かないと考えられるため，①の１行を加えるだけでなく，その表を削除するか，第４の２のように書き直す必要がある。

権限プロファイルは，OpenAIの公式資料上，ベータ版の機能とされ，仕様が変わる可能性がある。
本記事は，令和８年１０月３０日に確認したOpenAIの公式資料とGitHub上の報告に基づくものであり，個別のパソコンでの動作を保証するものではない。

第２　エラーが示していること
１　権限プロファイルとdefault_permissions

OpenAIの公式資料「Permissions」によれば，権限プロファイルは，Codexが利用者に代わって実行するコマンドについて，ファイルの読み書きの範囲と通信先をまとめて定める名前付きの設定である。
同資料は，組込みのプロファイルとして，読取りだけを許す「:read-only」，作業中のワークスペースの範囲等での書込みを許す「:workspace」，ローカルのサンドボックスの制限を外す「:danger-full-access」の三つを挙げている。

利用者が自分でプロファイルを作るときは，config.tomlに[permissions.名前]の表を書き，最上位のdefault_permissionsにそのプロファイル名又は組込みのプロファイル名を書く。
同資料の設定一覧では，default_permissionsの既定値は「None」（指定なし）とされ，予測可能な動作のために明示的に設定するよう求められている。

２　[permissions.network]と書いた場合

GitHubのopenai/codexリポジトリには，このエラーそのものを表題とする報告（Issue #14765，令和８年３月登録）がある。
報告者は，Linux上のCodex（報告された版は0.114.0）について，ネットワークの利用を許すつもりでconfig.tomlに[permissions.network]の表を書いたところ，Codexを起動しようとした時にこのエラーが表示されたと説明している。
他の環境や版でも同じ文言が表示されるかは，この報告からは分からない。

同じ報告に寄せられたコメント（令和８年３月）は，その投稿時点の設定の読込み処理が，[permissions]を名前付きプロファイルの表として扱い，default_permissionsが無い場合にはプロファイルの設定を受け付けないと説明している。
同コメントによれば，[permissions.network]と書くと，「network」という名前のプロファイルを定義したものとして読まれる。
したがって，ネットワークの設定を書いたつもりでも，プロファイルを一つ作り，その既定の指定を欠いた状態になる。

この報告は，令和８年１０月３０日の確認時点で未解決（open）であり，付いているコメントは利用者による１件だけである。
コメントの説明は利用者側の検証に基づくものであり，OpenAIの公式見解ではない点に注意を要する。

第３　config.tomlの場所

OpenAIの公式資料「Config basics」によれば，利用者ごとの設定はホームフォルダの「.codex」フォルダにあるconfig.tomlに保存される。
同資料は，プロジェクトごとの設定としてリポジトリ内の「.codex/config.toml」も読み込まれるが，それは利用者がそのプロジェクトを信頼済みとした場合に限られると説明している。

Windows版のChatGPTデスクトップアプリについて，公式資料「ChatGPT desktop app for Windows」は，Windows上のCodexと同じ「%USERPROFILE%\.codex」をCodexのホームフォルダとして使うと説明している。
そのため，Windowsで利用者ごとの設定を確認するときは，通常，「%USERPROFILE%\.codex\config.toml」を開くことになる。

（続きを読む...）Codexが起動しない「does not set default_permissions」の原因と直し方―config.tomlの権限プロファイル（AI作成）

目次

第１　結論第２　同時に何が起きるか第３　Google Driveのストリーミングとミラーリング第４　OneDriveのFiles On-Demand第５　Robocopyのマルチスレッド第６　フリーズの原因と断定しない第７　安全な実行順序第８　停止及び再開の方法第９　業務データを守るための確認第１０　確認用チェックリスト第１１　関連記事第１２　出典・参考資料
第１　結論

Google Drive，OneDrive及びRobocopyを同時に動かすと，ファイルの取得，読込み，書込み，メタデータ更新，キャッシュ及びネットワーク転送が重なり，PCの応答が遅くなることがある。
とりわけ，クラウド上にだけあるファイルを含む広いフォルダーを大量コピーの対象にすると，コピー処理がファイルの取得を促し，クラウド同期側の処理も増えることがある。

もっとも，同時実行だけでWindows全体のフリーズ原因と断定することはできない。
CPU，メモリ及びディスクに余裕があり，表示系の障害又は電源・ドライバーの問題がある場合は，別の原因候補を確認する必要がある。

再発を減らすための基本は，①大規模な同期と大量コピーを同時に始めない，②対象範囲を小さく分ける，③Robocopyの並列数を必要以上に増やさない，④ログを残す，⑤同期完了及びコピー結果を別々に確認する，という順である。

第２　同時に何が起きるか

クラウド同期フォルダーに見えるファイルは，すべてが同じ状態とは限らない。
ローカルに完全な内容があるファイル，必要時にクラウドから取得するファイル，同期中のファイル及びエラーで未同期のファイルが混在し得る。

大量コピーは，対象ファイルを順に読み，コピー先へ書き込む。
コピー元がオンデマンド取得の領域であれば，読込みに先立ってクラウドからの取得が必要になる場合がある。
同時に同期アプリ，ウイルス対策及び検索インデックスが新しいファイルを処理すれば，画面上では一つのコピーでも複数のプロセスが同じファイル群へアクセスする。

第３　Google Driveのストリーミングとミラーリング

Googleは，Drive for desktopの利用方法をストリーミングとミラーリングに分けている。
ストリーミングではファイルは主としてクラウドに保存され，アクセスしたときにオフラインでも利用できるよう取得される。
ミラーリングでは，マイドライブのファイルがローカル端末とクラウドの双方に保存される。

したがって，ストリーミング領域の大量コピーでは，ローカルに未取得のファイルが連続して取得される可能性を考慮する。
ミラーリング領域ではローカル容量を多く使うため，コピー先の容量だけでなく，ミラーの保存先及び一時領域の空きも確認する。

ストリーミングからミラーリングへ切り替える場合又はその反対の場合は，Googleの案内に従い，切替え前に同期が完了していることを確認する。
フリーズ又は同期エラーの直後にアカウントを切断し，キャッシュを削除し，又は同期方式を変えると，未同期ファイルと原因調査の記録を失うおそれがある。

第４　OneDriveのFiles On-Demand

OneDriveのFiles On-Demandでは，ファイルをエクスプローラーに表示しつつ，オンライン専用の状態にできる。
オンライン専用のファイルを開くと，端末へダウンロードされて利用可能になる。
「このデバイス上で常に保持する」状態のファイルは，端末へダウンロードされ，オフラインでも利用できる。

大量コピーの前には，コピー元の状態アイコンを確認する。
オンライン専用のファイルを大量に含む場合，単純なローカルディスク間コピーとは異なり，ネットワーク取得とローカル書込みが重なることを見込む。

第５　Robocopyのマルチスレッド

Robocopyは，ファイルを一つの場所から別の場所へコピーするWindowsのコマンドである。
`/MT`を指定するとマルチスレッドでコピーでき，スレッド数は1から128まで指定できる。

（続きを読む...）Google Drive・OneDrive・Robocopyを同時に動かすとPCが重くなる理由―クラウド同期と大量コピーの安全な運用（AI作成）

目次

第１　結論第２　最初に三つの停止を分ける１　遠隔接続だけが止まった場合２　表示系だけが止まった場合３　Windows全体が止まった場合第３　遠隔操作が追加する処理第４　直接操作よりフリーズしやすいか第５　発生時に残す記録第６　再現試験の方法第６の２　複数画面の条件を固定する第７　再発防止の優先順位第８　業務用PCでの運用第９　本記事の限界第１０　関連記事第１１　出典・参考資料
第１　結論

Chromeリモートデスクトップの利用中に画面が固まったときは，遠隔接続だけの停止，GPU・ディスプレイドライバー等の表示系の停止及びWindows全体の停止を分けて確認する必要がある。
また，「操作する側のPC（クライアント）」と「操作される側のPC（ホスト）」のどちらで停止したかを最初に固定する。
自宅PCから事務所PCを操作する場合と，事務所PCから自宅PCを操作する場合とでは，クライアントとホストが逆になる。

ホストでは画面の取得・転送が，クライアントでは受信した画面データの展開（デコード）と描画が加わる。
したがって，遠隔操作は双方のPCに追加処理を生じさせ，表示系に不安定さがあるPCでは症状を顕在化させる要因になり得る。

もっとも，遠隔接続中にフリーズしたという時間的な一致だけで，Chromeリモートデスクトップが原因である，又は遠隔操作の方が常にフリーズしやすいと断定することはできない。
CPU，メモリ及びディスクに余裕があっても表示系で止まることがあり，反対に，クラウド同期，大量コピー，バックアップ又はAIの子プロセスが同時に動いていれば，遠隔操作以外が主因であることもある。
遠隔操作だけが原因と決めず，「根本原因」と「症状を出す追加要因」を分けて評価する。

第２　最初に三つの停止を分ける
１　遠隔接続だけが止まった場合

遠隔画面は更新されないが，事務所PCの前ではマウス及びキーボードが動き，音声，ネットワーク又は他のサービスも正常である場合，Windows全体ではなく遠隔接続経路の停止を疑う。
この場合は，別端末からの再接続の可否，Chromeリモートデスクトップの接続状態，双方の通信状態及び接続が切れた時刻を確認する。

Googleは，Chromeリモートデスクトップを利用して別のコンピューター上のファイル及びアプリへアクセスできると説明している。
接続相手はアプリ，ファイル，メール，文書及び履歴へ広くアクセスできるため，遠隔画面だけの問題であっても，安易に認証情報を共有せず，利用者及び接続経路を確認する必要がある。

２　表示系だけが止まった場合

遠隔画面と事務所PCの画面がともに停止しても，音声，Caps Lockランプ，ネットワーク又はバックグラウンド処理が生きている場合，GPU，ディスプレイドライバー，Desktop Window Managerその他の表示系を分けて確認する。
Windowsには，デスクトップの内容を取得して遠隔デスクトップや共同作業へ利用できるDesktop Duplication APIがある。
これはChromeリモートデスクトップが特定のAPIを必ず使うことを意味しないが，遠隔表示がOSの表示処理と無関係ではないことを理解する手掛かりになる。

３　Windows全体が止まった場合

事務所PCのマウス，キーボード，画面及びネットワークがそろって応答せず，電源ボタンによる強制終了を要した場合は，Windows全体のハードハングとして扱う。
再起動後にKernel-Power Event 41が残っていても，それは正常なシャットダウンを完了しないまま再起動したことを示す記録であり，遠隔操作，GPU，電源又は特定アプリを原因と確定する記録ではない。

第３　遠隔操作が追加する処理

操作される側のPC（ホスト）では，アプリの通常処理に加えて，画面の変化を取得し，遠隔側へ送る処理が加わる。
操作する側のPC（クライアント）では，受信した遠隔画面のデータを展開（デコード）して描画する処理が加わる。
画面の解像度，複数ディスプレイ，動画，スクロールの多い画面又は頻繁なウィンドウ切替えがあると，静止画面を表示する場合より表示更新が増える。

Codexその他のAIアプリをクライアント側で動かしている場合は，AIアプリのローカル処理及び描画と，遠隔画面の展開・描画が同じPCで重なる。
AIアプリをホスト側で動かしている場合は，AIアプリのローカル処理及び描画と，画面取得・転送がホスト側で重なる。
どちらのPCからどちらを操作したかを記録しなければ，負荷の所在を逆に評価するおそれがある。

（続きを読む...）Chromeリモートデスクトップ利用中にWindows 11がフリーズする場合の切り分け―遠隔接続，表示系及びPC本体の停止を区別する（AI作成）

目次

第１　AIの回答と計算書の検証を分ける第２　最初に四つの確認対象を分ける第３　元データと計算条件を固定する１　原資料を残してから作業する２　法的な前提をプロンプトだけに残さない第４　数式と参照範囲を調べる１　合計値だけでなく式を見る２　検索・転記では一致しない場合も試す３　境界値と計算順序を確かめる第５　別の方法で照合してから使う１　同じAIへの再質問と独立した検算は別である２　AIの変更範囲を確認する第６　以前の表示値が残っていても再計算できるとは限らない第７　入力してよい資料と検証記録を確認する第８　出典と関連記事
第１　AIの回答と計算書の検証を分ける

生成AIにExcelの数式を提案させると，関数名を知らなくても表の集計や転記を補助してもらえる。
しかし，もっともらしい説明が付いていることと，請求額，支給額又は損害額が正しいことは別である。
法務で計算書を扱う場合は，元データ，適用する計算条件，数式及び表示結果を分けて確認したい。

MicrosoftのCopilot in Excel公式FAQは，誤りや誤解釈，不正確な結果があり得ることを示し，金融・法律・医療等の慎重さが必要な分野の判断での利用を避けるよう案内している。
本稿は，AIへ法的判断を任せる方法ではなく，数式作成等の補助を利用した計算書を人が確認するための実務上の提案である。
製品説明の確認基準日は令和８年１０月２８日である。

第２　最初に四つの確認対象を分ける
確認対象確認する問い誤りの例元データ原資料と値・単位・期間が合うか円と千円，時間と分の混同計算条件どの基準・契約・期間を適用するか異なる適用期間の条件を流用数式対象範囲と計算順序が合うか最終行の集計漏れ，参照先の誤り出力再計算後も結果を再現できるか古い表示値を現在の結果と誤認

数式が数学的に正しくても，適用する規程や対象期間を誤れば，実務上の結論は誤り得る。
例えば給与計算では，どの版の賃金規程をどの期間へ適用するかという確認が，Excelの操作に先行する。
規程群と実装の関係は，就業規則・人事規程・給与計算を横断点検するで扱っている。

第３　元データと計算条件を固定する
１　原資料を残してから作業する

受領したファイルをそのまま上書きせず，元ファイルと検証用の作業コピーを分ける方法が有用である。
元データの取得元，取得日時，対象期間，単位，作成者及び訂正の有無を記録しておくと，結果の違いを追いやすい。
ファイルのハッシュ値は同じバイト列かを照合する手掛かりになるが，元データの内容が真実であることまでは証明しない。

２　法的な前提をプロンプトだけに残さない

計算に用いる契約条項，規程の版，基準日，対象者，対象期間及び端数処理を，計算書又は対応する説明資料に残す方法が考えられる。
AIとの会話にしか前提が残っていない状態では，他の担当者が同じ結果を再現しにくくなる。
条件が争われている場合は，一方の条件を確定事実として埋め込まず，前提ごとの試算を区別する。

法律上どの条件が正しいかは，条文，判例，契約及び事実関係から別に判断する。
AIが選んだ式を，適用する法的基準の根拠にしない。

第４　数式と参照範囲を調べる
１　合計値だけでなく式を見る

合計値が予想に近い場合でも，集計範囲の開始行と最終行，別シートの参照，非表示の行，フィルター及び合計行の扱いを確認する。
同じ表に数式セルと手入力の固定値が混在していないかも調べたい。
表示形式による丸めと，数式で行う丸めを分け，どの段階で端数処理したかを確認する。

２　検索・転記では一致しない場合も試す

（続きを読む...）生成AIで作ったExcel計算書をどう検証するか―数式，参照範囲，計算条件と原本保存（AI作成）

目次

第１　入力前に確認するのはアイコンではなく利用条件である第２　アカウント，プラン及び機能を分けて確認する１　個人用と職場用の分離が意味すること２　同じ製品名でも確認単位をそろえる第３　非学習，保存及び外部連携は別々の問題である１　個人向けアプリ内Copilotにも非学習の説明がある２　学習に使わないことは保存しないことではない３　社内資料の参照権限と外部への接続を確認する第４　会社情報と依頼者情報の入力を判断する１　個人情報と秘密保持の確認を分ける２　東京弁護士会の記事の対象と限界第５　入力前と誤入力時の運用を決める第６　機能の終了と保存済み資料の扱いを混同しない第７　出典と関連記事
第１　入力前に確認するのはアイコンではなく利用条件である

Copilotの画面が同じになっても，会社の情報を入力してよいかどうかが一律に決まるわけではない。
現在のアカウント，契約しているプラン，利用する機能，入力する情報及び会社の承認条件を確認する必要がある。
個人用だから直ちに違法，仕事用だから無条件に安全という判断は，いずれも避けたい。

Microsoftは，個人用と職場・学校用のCopilotを共通のアプリから利用できるようにする変更を説明している。
同社の説明では，個人用アカウントと職場・学校用アカウントの境界は維持され，職場・学校用には組織の管理が引き続き適用される。
本稿は，令和８年１０月２８日に確認した公式資料を基に，この変更に伴う業務利用の確認順序を整理する。

ここで示す確認表と運用方法は実務上の提案であり，特定のサービス又は利用方法の適法性を一律に認定するものではない。
サービスの画面や提供状況は更新されるため，実際に利用する時点の説明と設定も確認する。

第２　アカウント，プラン及び機能を分けて確認する
１　個人用と職場用の分離が意味すること

MicrosoftのCopilotアプリの更新案内は，個人用と職場用のデータが相互の体験に反映されない設計を説明している。
これは，利用者が個人用の画面へ会社の文書を貼り付ける操作まで防止するという説明ではない。
設計上の分離と，どちらのアカウントへ情報を入力したかという操作上の事実を分けて確認したい。

同案内には，リンク済みの複数の個人用アカウントの対象履歴等がまとめられる場合の説明もある。
この個人用アカウント間の取扱いを，会社のアカウントとのデータ統合と混同しない。

２　同じ製品名でも確認単位をそろえる
確認単位確認する内容記録の例アカウント個人用か，組織の管理対象か所属組織とサインイン中のアカウント契約・プラン誰が契約し，どの条件が適用されるかプラン名と確認した契約資料の日付利用機能単独アプリか，Excel等のアプリ内か，外部連携があるか利用したアプリ，機能及び接続先入力情報社内資料，顧客情報又は取引先の秘密情報を含むか情報の種類と社内で認めた利用範囲

製品名又は有料・無料という区分だけでは，適用されるデータの取扱いを十分に特定できない。
承認時の説明資料と，実際に使うアカウント・機能の組合せが一致するかを確認する方法が有用である。

第３　非学習，保存及び外部連携は別々の問題である
１　個人向けアプリ内Copilotにも非学習の説明がある

Microsoftの個人向けMicrosoft 365アプリのプライバシー説明は，対象となるアプリ内Copilotのプロンプト，応答及びファイル内容を基盤モデルの訓練に使用しないとしている。
この資料は，個人用Microsoftアカウントで使うMicrosoft 365アプリ内のCopilotを対象とし，単独のCopilotアプリについては別の説明へ案内している。
したがって，個人用という名称だけで学習利用を決め付けることも，この説明を個人向けCopilotの全機能へ広げることも適切ではない。

２　学習に使わないことは保存しないことではない

Microsoftの組織向けCopilotのデータ保護説明は，基盤モデルの学習への不使用と，プロンプト・応答・引用等の活動履歴の保存を別々に説明している。
同資料は，管理者による検索や保持ポリシーの管理にも言及している。
履歴が画面に見えるか，サービス側に何が保存されるか，誰が管理できるかを一つの設定として扱わない。

（続きを読む...）Copilotに会社の情報を入力してよいか―個人用・仕事用アカウントとアプリ統合後の確認事項（AI作成）

目次

第１　結論第２　使用枠が回復する仕組みを分ける１　通常の周期更新２　自動リセット３　保存済みリセット４　有料リセットと追加クレジット第３　次回の回復日時が変わる理由第４　現在の残量とリセットを確認する方法第５　回復理由を調べるときの注意点第６　関連記事第７　出典と確認時点
第１　結論

Codexの週間使用枠が，表示されていた回復日時より前に１００％へ戻ることがある。
OpenAIの公式ヘルプは，通常の周期更新とは別に，対象者の利用枠へ直接適用する自動リセット，後から使う保存済みリセット及び購入する即時リセットを説明している。
ただし，残量や次回日時の変化だけでは，個別のアカウントにどのリセットが適用されたかを特定できない。

本記事は，令和８年１０月２８日に確認した公式資料に基づく説明である。
無料のリセット特典には提供や時期の保証がないため，臨時回復を前提に作業期限を組まず，現在の利用状況と次回の回復日時を確認する必要がある。

令和８年１１月１日の補足として，使用枠そのものの拡大と，消費済みの枠を回復させるリセットを分けて考える必要がある。
OpenAIはProのWork・Codex使用枠の拡大を公式ヘルプで説明しているが，その告知だけから，個別のアカウントで観測した回復を特定のリセットによるものと断定することはできない。

第２　使用枠が回復する仕組みを分ける
１　通常の周期更新

公式ヘルプは，通常のスケジュールに沿った利用枠の回復と，一回限りのリセットを区別している。
次に使える時刻を，上限に達した時刻から一律に７日後と決めつけず，利用状況に表示される対象枠と回復日時を確かめる。
「毎週月曜日の更新ではない」という説明だけから，直近１６８時間の消費分が順番に失効する方式だと結論付けることもできない。

２　自動リセット

OpenAIが付与する自動リセットは，特典の対象に選ばれたアカウントと利用枠へ直接適用され，利用者が使用する操作は不要である。
グローバルリセットとも呼ばれるが，全アカウント又は全ての利用枠を対象とする意味ではない。
保存済みリセットの残数へ追加される仕組みとも異なり，提供の有無や時期は保証されていない。

３　保存済みリセット

保存済みリセットは，アカウントへ保存され，期限内に利用者が使用する無料の使い切り特典である。
受け取っただけでは使用枠は回復しない。
アシスタントへ使用を依頼する場合も，公式ヘルプに記載された設定と利用条件を確認し，自動リセットとは分けて扱う。

公式ヘルプが示す保存済みフルリセットの対象は，Plus及びBusiness Standardでは５時間枠と週間枠，Pro 100・Pro 200・Pro 500では週間枠である。
同日に確認した公式料金ページも，現在のProには５時間の制限がないと説明している。
他のプランの画面を見て，自分にも同じ枠があると推定しない。

４　有料リセットと追加クレジット

有料の即時リセットは，一部のPlus及びProの個人アカウントに提供され，後から使うために保存するものではない。
該当プランに加入しているだけで購入できるとは限らない。

追加クレジットは，プラン内の利用枠を使い切った後に，対象の利用を残高から消費して続ける仕組みである。
利用枠を回復するリセットとは区別し，購入画面の対象，料金及び自分の契約条件を確認する。

（続きを読む...）Codexの週間使用枠が予定日前に回復する理由―自動リセット・保存済みリセットと確認方法（AI作成）

目次

第１　本記事の対象と結論１　本記事の対象２　結論第２　CAIOとは何か１　価値創出とリスク統制を結び付ける役割２　CAIOが全ての責任を引き受けるわけではない第３　CAIOの権限と組織体制１　経営に直結する報告経路２　全社AIステアリングコミッティ３　停止・差止めの権限第４　RACIで責任分担を可視化する１　RACIの４つの役割２　高リスクAIの例３　承認フローは危険度に応じて変える第５　KPIは利用回数だけで評価しない１　５領域を分ける２　利用率と事業成果を分ける３　承認の速さも測定対象にする第６　法務部門と法律事務所の役割１　法務部門はAI利用の唯一の責任者ではない２　法律事務所への当てはめ第７　組織変革と評価を分けない１　AIツールの配布だけでは足りない２　JAPAN AIの公開イベント資料の位置付け第８　導入初年度に何をするか１　最初の９０日２　パイロットから本番化へのゲート第９　関連記事第１０　出典・参考資料
第１　本記事の対象と結論
１　本記事の対象

本記事は，AIセーフティ・インスティテュート（AISI）が令和８年３月１日に公表した「Chief AI Officerガイドブック」及び「Chief AI Officer設置・AIガバナンス実務マニュアル」Version１．００を基に，民間企業におけるChief AI Officer（CAIO）の役割を整理するものである。
日本の国の行政機関におけるAI統括責任者の制度そのものや，個別のAIサービスの適法性を論じる記事ではない。

２　結論

民間企業にCAIOという名称の役員を置くことが，AISI資料によって一律に法的義務とされたものではない。
しかし，生成AIを含むAIの利活用が複数部門に広がると，価値創出，法令遵守，情報セキュリティ，個人情報，調達，人材育成及び事故対応をまたぐ意思決定が必要になる。
その場合に重要なのは，肩書を新設すること自体ではなく，誰が決め，誰が実行し，誰に相談し，誰に報告するかを文書化することである。

第２　CAIOとは何か
１　価値創出とリスク統制を結び付ける役割

AISIのガイドブックは，CAIOを，AIをデータ戦略及び技術戦略と一体で活用し，AIのリスクを経営課題として扱いながら，企業価値と信頼の確保を主導する役割と整理している（ガイドブック３頁～４頁）。
AIを使える人が増えたかどうかだけでなく，経営戦略との整合，投資優先順位，KPI・ROI，リスク及び重点ユースケースを一体で扱う点が特徴である。

２　CAIOが全ての責任を引き受けるわけではない

ガイドブックは，CAIOが方針策定，推進，統制及び説明責任を担う一方，個別案件の事業上の最終意思決定は当該事業責任者が担い，会社法その他の法令に基づく最終的な法的責任の所在を変更するものではないと明記する（同４頁）。
したがって，CAIOを置いたことやAIベンダーに委託したことを，事業部門，経営機関又は他の管理部門の責任が当然に移転する根拠とすることはできない。

第３　CAIOの権限と組織体制
１　経営に直結する報告経路

ガイドブックは，CAIOをCEO直下の独立したC-suiteとして置くことを推奨案とし，他のCxOの下に置く場合でも，CEO又は経営会議への直接報告経路と，リスク判断の牽制が働く会議体を社内規程で確保することを示す（同９頁）。
重要なのは情報システム部門の中だけで完結させないことである。
事業部門，法務・コンプライアンス，セキュリティ，個人情報，人事及び調達を巻き込む権限と手続が必要になる。

２　全社AIステアリングコミッティ

AISI資料は，CAIO，CDO，CIO，CTO，CISO，法務・コンプライアンス部門，データ保護責任者（DPO），人事部門及び主要事業部門等が参加する全社AIステアリングコミッティを例示している（実務マニュアル１９頁～２０頁）。
その議題として，新規ユースケースの採否，KPIの確認，インシデント・苦情の報告と是正，資源配分及び重大インシデントの対応方針等が挙げられている。

３　停止・差止めの権限

ガイドブックは，権利又は安全への影響が高いユースケースについて，CAIOに本番投入の停止・差止めを含む否認権を付与し，全社会議体の承認と人間による最終判断を求める体制が望ましいとする（ガイドブック６頁）。
これは，CAIOの役割を助言に限るのか，一時停止の権限まで与えるのかを，危険度に応じて先に決めるべきことを意味する。

第４　RACIで責任分担を可視化する
１　RACIの４つの役割

RACIは，業務ごとの関与者を次の４種類に分ける方法である。

（続きを読む...）Chief AI Officer（CAIO）とは―日本AISIガイドが示す権限・責任，RACI，KPI及び法務部門の役割（AI作成）

目次

第１　アンソロピックの目論見書で読むべき点第２　PBCは公益目的を組み込んだ営利会社である１　株主利益と公益目的をどう扱うか２　利用者への直接の権利とは区別する第３　種類株式ごとに権限を分けて読む第４　LTBTの取締役選任権にはどのような意味があるか１　過半数の取締役を選ぶ仕組み２　特定の一席には委員会と従業員が関与する第５　創業者側の50.1％は誰の権限か第６　統治構造は変更できるのか１　LTBTが賛成する場合と賛成しない場合２　一般株主への制約も開示されている第７　赤字額と現金の流出額を混同しない第８　AI利用企業の法務が確認する事項第９　参照資料
第１　アンソロピックの目論見書で読むべき点

アンソロピック（Anthropic）の目論見書を読む際は，売上や赤字に加え，誰が会社の意思決定に関与するかを確認する必要がある。
同社の統治は，公益目的を掲げる会社形態，独立したトラストによる取締役選任，創業者側の一般議決権，従業員の特定事項への関与を組み合わせた構造である。

特に，トラストが取締役会の過半数を選任することと，創業者側が一般株主決議で50.1％の議決権を持つことは，対象の異なる権限である。
両者を一つの持株比率や「支配権」にまとめると，誰が何を決めるのかが分からなくなる。

本記事は，2026年10月26日付のForm S-1に記載された構造を解説する。
同社も同日，S-1を提出したことを公表した。
ただし，対象文書は募集株数・価格等が未記入の予備的な版である。
IPO後に予定する仕組みを含み，提出されたことから上場完了やSECによる内容の保証を意味するものではない。

第２　PBCは公益目的を組み込んだ営利会社である
１　株主利益と公益目的をどう扱うか

同社の会社形態であるPBC（Public Benefit Corporation）は，非営利法人ではない。
デラウェア州の会社法上，営利会社として，株主の金銭的利益，事業によって重大な影響を受ける者の利益，特定の公益目的を取締役会が衡量する枠組みである。
デラウェア州会社法362条(a)・365条(a)

S-1では，高度なAIを責任をもって開発・維持し，人類の長期的な利益につなげるという趣旨の目的が説明されている。
投資家への利益と公益の関係を，単なる企業理念だけでなく，会社の統治の問題として扱う点に特徴がある。

もっとも，どの判断が公益目的に適合するかについて，S-1は定性的な目標や取締役会による基準設定を説明している。
PBCという名称だけで，各製品の安全性や将来の経営判断の正しさが保証されるわけではない。
根拠はS-1の「Our Governance Structure and Its Goals」である。

２　利用者への直接の権利とは区別する

公益目的があることから，個々の利用者にその実現を直接請求する権利が当然に生じるとはいえない。
デラウェア州会社法365条(b)は，公益目的から利益を受けるという理由だけで，その者に対する取締役の義務が生じるという扱いを採っていない。

これは，他の契約や法令に基づく権利まで否定する意味ではない。
AI利用企業にとっては，公益目的を確認することと，自社が契約上どの権利を持つかを確認することは，別々の作業である。

第３　種類株式ごとに権限を分けて読む

S-1の表紙に続く説明は，IPOに関連する種類株式の設計を示している。
主要な違いは次のとおりである。

種類主な権限・役割Class A原則として一株一票の議決権を持つ。Class N原則として議決権を持たない。法定例外や譲渡時の転換等がある。Class TLTBTが保有し，Class T取締役の選任・解任に関わる。経済的権利はない。Class FFounder LLCが保有予定の一株。一般に株主へ付議される事項について総議決権の50.1％を持つ。経済的権利はない。Class E創業者を除く従業員向け。特定の事項への投票に関与し，経済的権利はない。

ここで重要なのは，配当等の経済的権利，一般株主決議の議決権，取締役を選ぶ権限が一致するとは限らないことである。

（続きを読む...）アンソロピックの目論見書に見る企業統治―公益目的，トラストと創業者の議決権（AI作成）

目次第１　本記事の対象と結論１　短くする対象はプロンプトの文字数だけではない２　結論の要旨第２　トークン消費が増える範囲１　入力・出力・推論・ツール結果を分ける２　キャッシュされた入力も利用量である第３　長い依頼を４段階に分ける１　調査と進路決定２　起案３　独立した査読４　外部操作５　各段階の停止条件を決める第４　次の工程へ渡す最小限の引継ぎ１　残す項目２　会話全文をそのまま渡さない第５　共通の指示と案件ごとの情報を分ける１　変わりにくい指示を前に置く２　キャッシュと圧縮の効果を実測する第６　削ってはならない情報第７　法律調査・起案・査読の例第８　節約効果の測り方１　１回ではなく完了した仕事全体で測る２　品質と再試行も記録する第９　関連する山中弁護士ブログの記事第１０　出典・参考資料
第１　本記事の対象と結論
１　短くする対象はプロンプトの文字数だけではない

生成AIの利用量を抑えるために，依頼文を短くするだけでは足りない。
一つの長い会話に調査，起案，査読及び外部操作を詰め込むと，後の工程でも，すでに役目を終えた資料，試行錯誤及びツールの結果を繰り返し入力することがある。
他方，依頼文を短くしすぎて要件，例外又は出典が落ちれば，再質問と手直しが増え，仕事全体の利用量はかえって増える。

本記事は，法律調査，書面の起案及び査読を段階に分け，次の工程に必要な情報だけを引き継ぐ方法を整理する。
APIの従量課金と，定額サービスの利用上限は分けて考える必要がある。定額サービスでは，トークン数がそのまま請求額になるとは限らないが，利用上限，処理時間又は追加利用に影響することがある。
基準日は令和８年１０月２６日であり，製品の仕様及び料金は変更されるため，利用中のサービスの公式資料も確認する必要がある。

２　結論の要旨

結論は次の５点である。

①仕事を，調査と進路決定，起案，独立した査読及び外部操作に分ける。
②各段階で，入力，作る成果物，次へ渡す記録及び停止条件を決める。
③次の工程には，目的，対象の版と基準日，確認済みの資料，未確認事項，許された次の操作及び完了条件を渡し，会話全文を無条件に渡さない。
④共通して使う指示と，案件ごとに変わる事実・資料を分ける。
⑤節約効果は，入力だけでなく，キャッシュされた入力，出力，推論，再試行，ツール結果及び人の手直しを含む，完了した仕事１件の総量で測る。

第２　トークン消費が増える範囲
１　入力・出力・推論・ツール結果を分ける

OpenAIの開発者向け資料は，費用の見積りでは，全ての呼出しを対象に，入力，キャッシュされた入力，出力，推論，サブエージェント，再試行，ツール及び第三者サービスを確認するよう説明している。
入力には，利用者がその回に書いた依頼文だけでなく，システムの指示，ツールの定義，会話履歴，添付資料及び前のツール結果が含まれ得る。
したがって，「今回の質問は短い」という事実だけでは，入力全体が少ないとはいえない。

エージェントが同じ失敗を繰り返した場合，個々の呼出しが安くても総量は増える。
重いモデルを使った回数，サブエージェントの呼出し，検索・閲覧した資料の量及び長い結果を会話へ戻した回数を分けて記録する必要がある。

２　キャッシュされた入力も利用量である

プロンプトキャッシュは，繰り返される入力の処理を効率化する仕組みであり，前の回答をそのまま再生する仕組みではない。
同じ長い指示を毎回送っても，安定した先頭部分がキャッシュされれば単価又は待ち時間を抑えられる場合がある。逆に，日時，案件名又は毎回変わる資料を先頭へ置くと，共通部分が同じでもキャッシュが利用されにくくなることがある。

キャッシュされた入力の割合が高いことと，仕事全体の費用が下がったことも同じではない。
会話を圧縮した結果，通常の入力は減っても，キャッシュが作り直されることがあるため，圧縮前後の総量を比べる必要がある。

第３　長い依頼を４段階に分ける
１　調査と進路決定

（続きを読む...）生成AIの長いプロンプトを分割してトークン消費を抑える方法―法律調査・起案・査読の引継ぎ（AI作成）

目次

第１　結論１　スキルの数だけでなく，読み込まれる範囲を確認する２　本記事の範囲と確認日第２　スキルが読み込まれる３段階１　名前と説明２　SKILL.mdの本文３　参照資料とスクリプト第３　スキルが増えすぎたときに起きる問題１　常時のコンテキスト負担２　誤起動と競合３　無関係な参照資料の読込み第４　ゼロベースで整理する手順１　実際の作業単位で棚卸しする２　入口の説明を短く一意にする３　軽いルーターで主対象と必要な併用スキルを選ぶ４　重い作業を手動呼出しへ移す５　スキルの分割とエージェントへの分担を区別する第５　品質を落とさずにトークンを減らす１　削ってよい重複と残すべきゲートを分ける２　検証結果を再利用する条件を固定する３　トークン量以外の指標も見る第６　見直し後の確認方法１　代表依頼と非対象依頼で試す２　軽量化前後を同じ条件で比べる３　変更範囲を記録する第７　よくある質問１　全てを一つのスキルにまとめるべきか２　説明文は短ければ短いほどよいか３　スキルを減らせば４２９エラーは直るか第８　関連する山中弁護士ブログの記事第９　出典・参考資料
第１　結論
１　スキルの数だけでなく，読み込まれる範囲を確認する

Claude CodeやCodexで使うスキルが増えたときは，ファイル数を一律に減らすのではなく，①最初からモデルに示される名前・説明，②選ばれたときに読むSKILL.md，③必要な場合だけ読む参照資料・スクリプトを分けて見直すことが重要である。
常時読み込まれる短い情報が重なれば，全ての作業でコンテキストを使う。
説明の範囲が重なれば，関係の薄いスキルが選ばれ，長い本文や参照資料まで読み込まれる原因になる。

したがって，よく使う作業は短く具体的な入口から必要な資料だけへ案内し，まれに使う重い作業は手動で明示的に呼び出す構成が基本になる。
もっとも，一次資料の確認，機密情報の取扱い，外部への送信・公開の承認及び結果の読戻しは，トークン節約を理由に省略してはならない。

２　本記事の範囲と確認日

本記事は，スキルの数が増えたときの整理方法を，公開されているOpenAI及びAnthropicの公式資料に基づいて説明するものである。
特定の利用者のスキル数，トークン量，PCのパス又は社内の構成は掲載しない。
製品仕様の確認日は令和８年１０月２６日であり，設定名や読み込み方は変更されることがあるため，実施時には最新の公式資料を確認する必要がある。

第２　スキルが読み込まれる３段階
１　名前と説明

OpenAIのSkills公式資料では，スキルの名前と説明が先にモデルへ示され，利用者の依頼と合うスキルを選ぶために使われる。
OpenAIは，スキルが多い場合や説明が長い場合には一覧が短縮されることがあり，説明の重複は関係の薄いスキルの読込みにつながると説明している。

Anthropicも，Agent Skillsについて，最初は名前と説明を読み，必要になったときにSKILL.mdへ進む段階的な仕組みを説明している。
このため，説明文は単なる紹介ではなく，どの依頼で選び，どの依頼では選ばないかを決める入口である。

２　SKILL.mdの本文

SKILL.mdには，作業の順序，入力，成果物，停止条件及び確認方法を置く。
本文を短くすること自体が目的ではなく，その作業を安全に進めるために毎回必要な規則を残し，個別の場合にしか使わない説明を外へ分けることが目的である。

Claude Codeでは，自動選択を無効にして利用者が明示したときだけ呼び出す設定も用意されている。
破壊的操作，外部公開，本番更新又は利用頻度の低い管理作業は，名称だけが似た依頼から自動的に選ばれないよう，手動呼出しを検討できる。

３　参照資料とスクリプト

長い様式，分野別の資料，例外処理，検査スクリプト及び過去の事例は，必要なときだけ読む補助ファイルへ分ける。
SKILL.mdには，どの条件でどの資料を読むかを短く書き，関係のない参照フォルダを最初から全部読ませない。

段階的読込みは，資料を削除することではない。
必要な根拠や検査器を保持したまま，通常の依頼では入口だけを読み，該当する作業で初めて詳細へ進む設計である。

第３　スキルが増えすぎたときに起きる問題
１　常時のコンテキスト負担

（続きを読む...）Claude Code・Codexのスキルが増えすぎたときの整理方法―トークン消費，誤起動及び段階的読込み（AI作成）

目次

第１　結論―AIの回答ではなく原資料で調査を閉じる第２　法律調査で区別する資料１　法令本文と改正情報２　裁判例本文３　判例秘書等の有料判例データベース４　行政機関，弁護士会その他の公表資料５　解説記事，動画及びSNS投稿６　生成AIの回答７　検索先の選び方による見落としを点検する第３　解説から元の文書へ遡る方法１　まず解説が依拠した文書を特定する２　元文書の記載と解説者の付加を二列で分ける第４　裁判例の確認状態を七段階で残す１　検索したことと判旨を確認したことを分ける２　裁判例番号だけを並べない第５　調査記録に残す項目１　資料台帳２　未確認事項と限界第６　記事，法律相談及び裁判所提出書面で確認水準を変える第７　よくある質問１　裁判所ウェブサイトで見つからない判決は存在しないのか２　判例秘書で全文を開けば十分か３　AIにURLを読ませれば元資料を確認したことになるか４　解説記事に出典があれば原資料を読まなくてよいか第８　関連記事第９　出典・参考資料
第１　結論―AIの回答ではなく原資料で調査を閉じる

生成AIは，検索語の候補，論点の分解，長い資料の整理及び確認漏れの点検に利用できる。
しかし，AIが法令名，条文番号，裁判年月日又はURLを示しただけでは，法律調査は完了しない。

法律調査では，AIの回答を出発点にしても，最後は法令本文，裁判例本文，行政機関の公表資料その他の原資料を開き，記事又は書面に記載する命題をその資料が直接裏付けるかを確認する。
解説記事，動画，SNS投稿及びAIの要約は，論点や原資料を発見するために利用できるが，原資料の代わりにはしない。

特に裁判例は，「検索結果に出た」「事件番号を確認した」「全文を開いた」「記事中の命題を裏付ける判示を確認した」という状態を分ける必要がある。
判例秘書等の有料判例データベースを利用した場合も，一覧，事件ヘッダー，編集者による要旨及び判決本文を区別する。

確認する対象発見に使える資料最終的に確認する資料記録すること現行法令AI，検索，解説記事e-Gov法令検索等の法令本文法令名，条，基準日，施行日過去の法令AI，法令索引，文献当時の法令本文，改正法，附則対象時点，改正前後，経過措置裁判例AI，解説，裁判例検索，判例DB判決本文裁判所，年月日，事件番号，確認頁，判示主体行政の取扱いAI，まとめ記事，動画所管官庁の通知，通達，FAQ等作成主体，表題，版，更新日，該当箇所評価又は予測AI，論文，解説，動画評価方法，元データ，限界を記した資料事実と評価，対象範囲，未確認事項
第２　法律調査で区別する資料
１　法令本文と改正情報

現行法令は，原則としてe-Gov法令検索で法令名，法令番号，条文及び施行時点を確認する。
条文の文言だけでなく，附則，施行日，経過措置及び委任先の政省令が結論に影響することがある。

過去の事件では，現在表示される条文だけを読んでも足りない。
対象となる行為又は処分の時点に適用された条文，改正法及び経過措置を確認する。
新しい法令や改正直後の法令は，公的データベースへの反映時期も確認し，必要に応じて官報又は公布資料へ遡る。

２　裁判例本文

裁判例を記事又は書面の根拠にする場合は，裁判所名，裁判年月日及び事件番号を照合し，判決本文の該当箇所を読む。
裁判所ウェブサイトの裁判例検索には全ての判決等が掲載されているわけではないため，限定した検索で見つからなかったことから直ちに「裁判例は存在しない」と結論付けない。

判決本文に同じ文章があっても，当事者の主張，前提事実，裁判所の認定，裁判所の法的判断及び反対意見等のいずれであるかによって意味が異なる。
本文中の主体と，その記載が採用されたか否かを確認する。

３　判例秘書等の有料判例データベース

判例秘書等の有料判例データベースは，裁判所ウェブサイトで発見できない裁判例，関連裁判例及び評釈を探す際に有用である。
ただし，データベースへログインしたこと又は検索結果に事件が表示されたことだけで，判決本文を確認したことにはならない。

確認状態は，未検索，検索実施，結果件数確認，一覧又は事件ヘッダー確認，全文確認，判旨確認及び記事中の命題との直接関連性確認に分ける。
全文を確認した場合は，データベース名，検索日，事件ID，確認した頁又は段落及び記事中のどの記載を支えるかを残す。

データベースの要旨又は解説は，判決本文そのものと区別する。
要旨から有用な検索語を得ることはできるが，記事へ判旨を書くときは，本文の文脈，事案及び射程を確認する。

４　行政機関，弁護士会その他の公表資料

行政機関のガイドライン，通知，通達，事務連絡，FAQ及び審議会資料は，作成主体，文書名，発出日又は更新日及び版を確認する。

（続きを読む...）生成AIで法律調査をする方法―一次資料・判例秘書・解説記事・動画の使い分け（AI作成）

目次

第１　結論第２　最初に「固まった」の意味を分ける１　特定のアプリだけが応答しない場合２　表示又は遠隔画面だけが止まった場合３　Windows全体が応答しない場合４　単に処理の完了を待っていた場合５　停止の型とログを対応させる第３　再起動前後に残す最小限の記録１　時刻と停止範囲２　最後のコマンドと処理の状態３　外部操作の成否第４　パフォーマンスモニターを「飛行記録装置」として使う１　事前に記録を始める理由２　優先して見るカウンター３　最後のサンプルの後に空白がある場合第５　イベントビューアー及びWindows Error Reportingを読む１　Event 41及び6008２　Application，System及び信頼性履歴３　ESENTのI/O待ちに関するイベント４　より詳しい記録が必要な場合第６　最後のコマンドと性能ログを突き合わせる第７　再現試験は一度に一つだけ変える第８　クラウド同期が関係するときの注意第９　ログに含まれる秘密情報を守る第１０　確認用チェックリスト第１１　関連記事第１２　出典・参考資料
第１　結論

Windows 11が固まった原因を後から調べるときは，フリーズ直前の時刻と最後の操作を確定し，パフォーマンスモニターの記録，イベントビューアー，Windows Error Reporting等を同じ時刻で突き合わせる必要がある。
一つのAIセッションしか動いていなくても，そのセッションが大きなPDFの読込み，OCR，広いフォルダー検索，ビルド又はテストを実行していれば，CPU，メモリ又はディスクの負荷原因になり得る。

他方で，クラウド同期，バックアップ，ウイルス対策，検索インデックス又はドライバーの処理が重なれば，画面上で操作していたアプリが原因でないこともある。
したがって，「直前に使っていたアプリ」と「同時刻に資源を多く使っていたプロセス」を分けて確認することが重要である。

第２　最初に「固まった」の意味を分ける
１　特定のアプリだけが応答しない場合

ウィンドウの切替え，タスクマネージャー及び他のアプリが動くなら，Windows全体ではなく特定のアプリ又はその子プロセスの停止を疑う。
アプリの「応答なし」，Application Hang，Windows Error Reporting及び同時刻のプロセス別CPU・メモリ・I/Oを確認する。

２　表示又は遠隔画面だけが止まった場合

音声，Caps Lockランプ又は別端末からの接続が生きているのに画面だけが更新されない場合は，GPU，ディスプレイドライバー，Desktop Window Manager又は遠隔操作経路の問題を分けて考える。
画面停止とWindows全体のハードハングを同じものとして扱わない。

３　Windows全体が応答しない場合

キーボード，マウス，画面及びネットワークがそろって応答せず，電源ボタンによる強制終了を要した場合は，ハードハング，電源，熱，ドライバー又はハードウェアを含めて確認する。
この場合は原因を示す情報自体をディスクへ書けないことがあり，ログが少ないことを正常の証明にしてはならない。

４　単に処理の完了を待っていた場合

AI画面の「考え中」又は経過時間は，モデルの応答待ちだけを示すとは限らない。
ローカルのシェルコマンド，ファイル検索，PDF変換又は外部ツールが継続中なら，画面上は一つのセッションでも複数プロセスが動くことがある。

５　停止の型とログを対応させる
停止の型優先して確認する記録注意点特定アプリだけApplication Hang，AppHangB1，信頼性履歴PC全体の停止と混同しない表示だけDisplay，WER，LiveKernelEvent（コードを確認する），TDRコードだけでGPU故障と断定しないWindows全体Event 41，6008，WHEA，ダンプEvent 41は前回の終了が正常でなかった記録であり，単独では原因を示さない

具体的な手順は，特定アプリだけ「応答なし」になる場合の調べ方及び３画面・複数ディスプレイ使用中の切分けを参照されたい。

第３　再起動前後に残す最小限の記録
１　時刻と停止範囲

少なくとも，①最後に正常に操作できた時刻，②固まり始めた時刻，③性能ログ又はアプリログの最後の記録時刻，④電源ボタンによる強制終了の時刻，⑤Windowsの起動時刻及びEvent 41の記録時刻を分ける。
Event 41は再起動後に記録されるため，その時刻だけをフリーズ開始時刻として検索しない。

時計が見えなければ，別端末の写真，遠隔接続の切断記録又はPowerButtonTimestamp（値の形式は公式資料に説明がないため，時刻として読むときは他の記録と照合する。）を手掛かりにする。
確認できない秒単位の時刻を推測で補わず，確認できる時間帯として残す。

マウス，キーボード，画面，音声及びネットワークのどれが止まったかも記録し，アプリ停止，表示停止及びWindows全体の停止を区別する。

２　最後のコマンドと処理の状態

（続きを読む...）Windows 11がフリーズした原因を後から調べる方法―最後のコマンド，パフォーマンスモニター及びイベントビューアー（AI作成）

目次

第１　改定の適用日と，確認する二つの問題第２　通常の不満や誤りの指摘まで禁止する趣旨ではない１　ポリシー本文と公式発表の説明２　会話終了とアカウントへの措置は同じではない第３　法律相談・書面作成で確認する条件１　具体的な助言や署名・提出用の法律文書２　一般情報や内部作業にも除外の条件がある第４　法律事務所の手順へ落とし込む１　修正要求を，検証できる指示にする２　提供前の審査と，入力資料の取扱いを分ける第５　関連記事と出典
第１　改定の適用日と，確認する二つの問題

Anthropicは，２０２６年１０月８日，利用ポリシーの更新を発表した。新しいポリシーの適用予定日は同年１１月１２日である。本記事は１０月２６日時点で公表された内容を扱う。

確認したいのは，AIに対する批判や修正要求がどこまで認められるかという問題と，法律相談・書面作成に利用する際の条件である。「Claudeに怒ると直ちに利用停止になる」「法律業務には使えない」という理解では，公式資料の条件を捉えられない。

以下では，利用ポリシー本文と，改定についての公式発表を分けて読む。利用ポリシーはサービスの利用条件であり，日本の法令又は裁判所の判断そのものではない。

第２　通常の不満や誤りの指摘まで禁止する趣旨ではない
１　ポリシー本文と公式発表の説明

ポリシー本文には，モデルに対する継続的で不必要な虐待的又は残酷な言動を禁止する項目がある。公式発表は，目的を見いだせない反復的な残酷行為という極端な場合を対象とし，通常の不満，反論，暗い題材の創作，テスト及び研究まで禁止する趣旨ではないと説明している。

この説明を踏まえると，「その判例は実在しない。原典を確認して訂正してほしい」と求めることまで，禁止された行為として扱う理由はない。一方，今回確認した公式資料には，どの言葉を何回使えば該当するという数値基準は示されていないため，独自の判定基準を作って断定することも避けたい。

２　会話終了とアカウントへの措置は同じではない

公式発表は，この項目について会話の終了を主な対応方法と説明している。他方，ポリシーの一般的な執行条項には，警告，利用や機能の制限，停止及び終了等が留保されている。「必ずアカウントが停止される」とも，「会話が終わるだけで他の措置は絶対にない」ともいえない。

また，ポリシー本文は，出力が遮断されたことだけで利用者の違反を意味するわけではないとしている。画面上の拒否や会話の終了だけから，規約違反の認定があったと推測しないことが大切である。

第３　法律相談・書面作成で確認する条件
１　具体的な助言や署名・提出用の法律文書

ポリシーの高リスク利用に関する項目では，個人の権利・義務・責任や具体的な法律問題についての助言，署名又は提出のための法律文書の準備などが対象として挙げられている。

対象となる利用では，その分野の出力を評価できる訓練又は経験を備えた人が，提供又は決定の実施前に内容を実質的に審査し，必要な変更を行えることが求められる。法律上資格が必要な場合はその資格も必要であり，審査者は正確性や適切性に責任を負う。対象となる人へのAI利用の明確な開示も条件である。開示に際し，Claude等の製品名まで示すことを同ポリシーが要求しているわけではない。

公式発表によれば，人による審査と開示は，今回初めて導入された条件ではない。今回の改定は適用範囲や条件を明確にするものと説明されている。

２　一般情報や内部作業にも除外の条件がある

ポリシーは，個人の事情に当てはめない一般情報や，最終的に提供される高リスクの推奨そのものではない内部の起案・調査・要約・分析等を除外する。この条件を落として，「要約なら全て対象外」「内部で作れば最終的な助言にも条件はない」と広げることはできない。

例えば，公開法令の見出しを整理する作業と，特定の依頼者が契約を解除できるかについて結論を出して伝える作業では，成果物の役割が異なる。作業名だけで区分せず，誰に何を提供するのかを先に決める方法が考えられる。

第４　法律事務所の手順へ落とし込む
１　修正要求を，検証できる指示にする

次は，本記事の運用提案であり，Anthropicが定めた必須の指示文ではない。

「間違いを直して」だけで終えず，問題のある記載，確認すべき原資料，修正できる範囲及び未確認の場合の扱いを指定する。例えば，「この判例引用について，裁判所，年月日，事件番号及び判決本文の該当箇所を確認する。本文が得られなければ引用を確定せず，未確認の理由を示す」と指示する。

文章が自然になったことと，法的根拠が確認できたことは分けて判断する。判例秘書等で検索できたことだけを，対象判決の本文まで照合したことに置き換えない。誤りの原因と修正後の確認方法を残すと，同じ誤りへの対処を手順書へ反映しやすい。

２　提供前の審査と，入力資料の取扱いを分ける

依頼者へ渡す助言又は提出用書面では，担当者，確認する資料，修正権限及び提供前の確認時点を決める。AIを用いたことの開示を誰がどの場面で行うかも，成果物の利用方法に合わせて整理する。

これは利用ポリシーへの対応を具体化する提案であり，AI利用の開示だけで，依頼者の秘密や有料文献を外部へ送信できるという意味ではない。入力資料を扱う権限・契約と，完成した助言や書面の審査は，別々に確かめる必要がある。

第５　関連記事と出典

- 弁護士のClaude Code Skills活用法―調査・書面作成・記事更新を手順書にする

（続きを読む...）Claudeへの暴言は規約違反か―２０２６年１１月の利用ポリシーと法律実務（AI作成）

目次

第１　本記事の対象と結論１　対象と基準日２　結論第２　高性能AIの安全制限と防御者向けの仕組み１　一般向けモデルでは攻撃につながる作業が止められる２　防御者を確認して制限を緩める第３　AnthropicのCyber Verification Program１　三つのアクセス段階２　データの保持が条件とされている３　Claude Mythosの提供範囲第４　OpenAIのTrusted Access for CyberとDaybreak第５　日本政府の取組１　Project YATA-Shield２　金融分野でのClaude Mythos Previewへのアクセス３　日本政府が防御者を認証する法律上の制度は確認できない第６　法律上の位置付け１　安全制限の緩和は不正アクセス禁止法上の承諾に代わらない２　不正指令電磁的記録の罪と「正当な理由」３　被害企業が攻撃元に侵入する権限は与えられていない第７　企業・法律事務所が確認すべき事項第８　出典１　事業者の公表資料２　政府資料３　法令４　関連記事
第１　本記事の対象と結論
１　対象と基準日

脆弱性の発見や侵入の再現に優れた高性能AIは，防御にも攻撃にも使える。
そのため，AnthropicとOpenAIは，一般向けのモデルでは攻撃につながる作業を止める一方，身元と用途を確認した防御者に限って制限を緩める仕組みを設けている。
本記事は，令和８年１０月２５日までに公表された両社と日本政府の資料に基づき，その仕組みと，日本の企業や法律事務所が利用する際の法律上の注意点を整理する。
両社の仕組みは事業者自身の公表資料による説明であり，運用の実態や個別の審査結果を独立に確かめたものではない。

２　結論

①AnthropicとOpenAIは，いずれも防御者であることの確認を条件に，サイバーセキュリティ関係の安全制限を緩める仕組みを公表している。
②Anthropicの仕組みのうち，止められる範囲が最も狭いSpecialized Accessについては，現時点では米国政府と協力して全ての組織を詳しく審査するとされている。
③日本政府は，令和８年５月１８日の関係省庁会議で取りまとめた「Project YATA-Shield」で，外国政府機関やAI開発者等との連携を施策に掲げている。
④OpenAIは，同年６月２２日の公表で，日本を含む各国・機関との間でTrusted Access for Cyberのパートナーシップを構築したとしているが，日本側の相手方や内容は示していない。
⑤金融分野では，片山財務大臣兼内閣府特命担当大臣が，同年６月２日，Project Glasswingの参加先に日本の政府と一部の金融機関が含まれ，Claude Mythos Previewへの日本のアクセスができたと述べる一方，実際に作業に入る時期は別であるとしている。
⑥AIの安全制限が緩められても，不正アクセス禁止法２条４項各号の行為に当たる操作を含む試験が不正アクセス行為から除かれるのは，アクセス管理者自身が行う場合のほかは，アクセス管理者等の承諾を得た場合であり，AI事業者の判断で変わるものではない。
⑦Anthropicの仕組みは，原則として参加組織にデータの保持を求めているため，試験で扱う秘密情報や個人データの扱いを事前に確認する必要がある。

第２　高性能AIの安全制限と防御者向けの仕組み
１　一般向けモデルでは攻撃につながる作業が止められる

Anthropicの令和８年１０月６日の公表資料によれば，同社がClaude Opus 5.5で実施した，攻撃的な場面を想定した複数段階のサイバー作戦の評価課題では，後記第３の確認制度を利用しない一般向けの状態で，全ての課題が最初の指示の段階で止められた。
OpenAIは，同年２月５日の公表資料で，フロンティアモデルを，資格情報の窃取のような明らかに悪意のある要求を拒否するように訓練するなどの緩和策を組み込んで設計していると説明している。
また，同社は，安全のための方針と判定の仕組みを調整している間，サイバーセキュリティ業務に従事する開発者やセキュリティ専門家がその影響を受ける可能性があると説明している。
他方で，Anthropicは，一般向けのモデルも，コードの確認，既知の問題の修正，自ら所有するソースコードの脆弱性の探索及びセキュリティ警報の選別には引き続き使えるとしている。

２　防御者を確認して制限を緩める

両社の仕組みは，事業者自身が利用者を確認し，用途に応じて止める範囲を狭める点で共通する。
もっとも，両社とも，確認を受けた利用者に何でも許しているわけではない。
OpenAIは，信頼済みのアクセスを利用する者も利用ポリシーと利用規約を守る必要があり，データの流出，マルウェアの作成・展開及び破壊的又は不正なテストは禁止されたままであると説明している。
Anthropicも，侵入テストを認めるRed Team Accessの段階で，ランサムウェアの展開，物理的なシステムの損傷，危険性の高い安全システムへの侵入テスト等，身体的な危害や大規模な障害につながる操作は引き続き即時に止めるとしている。
したがって，これらの仕組みは，正当な防御業務の範囲で安全制限を緩めるものと理解すべきである。

第３　AnthropicのCyber Verification Program
１　三つのアクセス段階

Anthropicは，令和８年１０月６日，Cyber Verification Program（CVP）を拡充し，三つのアクセス段階を設けると公表した。

（続きを読む...）高性能AIをサイバー防御に使うための防御者向け利用制度―AnthropicのCyber Verification Program，OpenAIのTrusted Access for Cyber，Project YATA-Shield及び不正アクセス禁止法（AI作成）

目次

第１　AIが新しい法律回答を作るサービスなのか第２　公式に案内されている機能と利用条件第３　弁護士本人の回答でも，自分の結論とは限らない第４　相談メモを弁護士へ持参する際の使い方第５　公開型の相談投稿と使い分ける第６　資料の位置付け
第１　AIが新しい法律回答を作るサービスなのか

「みんなの法律相談AI」は，弁護士ドットコムが提供する，対話を通じて事情を整理し，近い相談と弁護士の回答を探すサービスである。
令和８年１０月２５日に確認した公式案内は，表示するのは「みんなの法律相談」で弁護士が実際に回答した内容であり，AIが回答文を作ることはないと説明している。

そのため，利用する際は，AIが自分の事件について新しい法律上の結論を出す仕組みなのか，過去の相談と回答を探す仕組みなのかを区別する必要がある。
本記事は，公式案内と令和８年１０月２日の会社発表に基づく説明である。
個別の相談情報を入力した実測結果ではない。

公式案内：https://www.bengo4.com/ask/

第２　公式に案内されている機能と利用条件

令和８年１０月２日の会社発表は，β版について，無料・匿名で２４時間３６５日利用できる対話・検索型アシスタントと説明している。
困っている事情を質問を重ねて整理し，過去の相談・弁護士回答から近いものを抽出して，テーマごとに提示する仕組みである。

同発表には，会話内容をまとめた「相談メモ」を生成し，実際に弁護士へ相談する際の資料などに使えるという説明もある。
これらは提供者が公表した機能の説明であり，検索結果の適合性や，個々の利用者の紛争解決を保証するものではない。

公式案内は，次の画面で利用規約と免責事項を確認してチャットを開始するよう案内している。
無料・匿名という表示だけで入力内容の保存・利用・第三者提供の条件まで判断せず，開始前にそのサービスに適用される条件を確認されたい。

会社発表：https://www.bengo4.com/corporate/news/article/4c0yjybeb6az/

第３　弁護士本人の回答でも，自分の結論とは限らない

実際の弁護士が書いた回答を読めることと，その弁護士が自分の資料を確認して回答したことは別である。
表示された相談では，自分の問題と似た言葉が使われていても，契約内容，証拠，出来事の時期，相手方の主張などが異なる可能性がある。

例えば「会社を辞める」という同じ悩みでも，問題となる契約や説明したい事情が異なれば，確認すべき点も変わる。
検索結果を読む際は，回答の結論だけを切り出さず，元の質問，回答日，前提とされる事実や留保を一緒に確認されたい。

また，検索で見つかった回答が当時の制度を前提にしている可能性もある。
現在の自分の問題に当てはめるときは，適用される時点と原資料を確かめる必要がある。
詳しく入力したことや，複数の回答が似ていることだけで，結論の正しさを確定しないことが大切である。

AI法律相談の一般的な使い方と限界：https://yamanaka-bengoshi.jp/2026/10/11/ai-bengoshi-toha/

第４　相談メモを弁護士へ持参する際の使い方

相談メモは，自分の説明を準備するための補助資料として使うと整理しやすくなる。
次の情報を分けて残す方法が考えられる。

- AIとの対話で入力した事情と，入力していない事情。
- 見つかった過去の相談のURL，元の質問，回答日。

（続きを読む...）みんなの法律相談AIとは―過去の弁護士回答の検索と個別相談の違い（AI作成）

目次

第１　「匿名」と「非公開」を分けて考える第２　投稿後の編集・削除は自由にできるのか第３　退会すれば相談投稿も消えるのか第４　投稿前・相談前に確認すること第５　資料の位置付け
第１　「匿名」と「非公開」を分けて考える

弁護士ドットコムの「みんなの法律相談」に投稿する前に確認したいのは，表示名だけでなく，相談本文が誰に読まれるかという点である。
運営者のFAQは，投稿した相談がサイト内の検索等に反映され，インターネットを利用できる環境から閲覧できると説明している。

本記事は，公開型の「みんなの法律相談」について，令和８年１０月２５日に確認した公式FAQを整理したものである。
個別に弁護士へ相談するサービスや，「みんなの法律相談AI」のチャット入力の取扱いとは分けて読んでください。

名前を書かないことと，相手方や知人に事情を推測されないことは別である。
勤務先の規模，役職，出来事の日付，家族関係などを組み合わせると，関係者が自分の知っている事件と結び付ける可能性がある。
これは匿名性の保証に関する公式判定ではなく，公開投稿を考える際の注意点である。

誰にも知られたくない事実や，契約書・診療情報などの資料を詳しく示す必要がある場合は，まず非公開の個別相談経路を検討するのが適切である。
公式FAQも，相談を非公開にして投稿することはできないと案内している。

公開範囲の根拠：https://www.bengo4.com/faq/396/

非公開相談に関する案内：https://www.bengo4.com/faq/403/

第２　投稿後の編集・削除は自由にできるのか

公式FAQは，相談内容と弁護士の回答に矛盾が生じるおそれがあるため，投稿内容の編集は受け付けていないと説明している。
補足したい事情がある場合は，該当の投稿への追加投稿が案内されている。

削除についても，規約に反する内容の投稿を除き，一律では削除しないという運営方針が示されている。
「回答を読んだら消す」「事情が変わったら本文を書き換える」という使い方を前提にしない方がよいでしょう。

ただし，このFAQはサービス上の取扱いを説明するものである。
個別の投稿について法的に削除を求められるか，どのような対応が必要かという判断を，このFAQだけで決めることはできない。

誤って個人情報等を書いた場合は，投稿のURL，問題となる箇所，困っている事情を整理し，公式のお問い合わせ窓口で対応を確認されたい。
追加投稿で説明する際も，問題の情報を繰り返して広げないよう注意が必要である。
削除されることや，インターネット上の全ての複製が消えることを保証する趣旨ではない。

編集・削除の根拠とお問い合わせへの入口：https://www.bengo4.com/faq/59/

第３　退会すれば相談投稿も消えるのか

公式FAQは，退会すると登録情報は削除されるものの，「みんなの法律相談」の投稿内容は削除されないと説明している。
また，退会後はログインできず，マイページから「投稿した相談一覧」を確認できなくなると案内している。

したがって，相談投稿を消したいという理由だけで先に退会しても，目的を達成できるとは限らない。
退会前に，必要な相談URLや問い合わせの記録を控え，投稿の取扱いについて確認する方が混乱を避けられる。

退会に関する根拠：https://www.bengo4.com/faq/259/

（続きを読む...）弁護士ドットコムの相談は削除できるか―匿名・公開範囲・退会前の確認事項（AI作成）

目次

第１　Skillsでできることを整理する１　毎回の説明を，必要なときに読む手順へ移す２　スキル，CLAUDE.md及びメモリを使い分ける３　スキルが増えたときは入口と本文を分けて見直す４　スキルを使うエージェントの全体を捉える第２　法律事務所の手順書に残す６項目１　適用場面と入力資料２　成果物と根拠の対応３　停止条件と更新責任第３　公開資料の調査メモを作る例１　解説と元資料を別々に読む２　NotebookLMの引用表示を最終確認にしない３　手順書の検索先が狭すぎた場合の修正例第４　書面を点検する例１　編集できる範囲を入力に含める２　文章の読みやすさと根拠の点検を分ける第５　ブログ記事を更新する例１　現在の本文と変更案を対応させる２　公開後の確認まで手順に含める第６　導入時に誤解しやすい点１　allowed-toolsを権限の上限と考えない２　成功した例だけで採用しない第７　関連記事第８　出典・参考資料
第１　Skillsでできることを整理する

Claude CodeのSkills（スキル）は，繰り返し使う作業手順をファイルにまとめ，必要な場面で参照させる仕組みである。
法律事務所では，便利な指示文の収集から始めるより，何を入力し，どの資料まで読み，何を成果物とし，どこで止めるかを決めることが役立つ。

本記事では，公開資料の調査メモ，書面の点検及びブログ更新を例に，手順書を作る考え方を説明する。
機能の説明はAnthropic社の公式資料に基づき，業務への当てはめは本記事の提案として示す。
以下の例は，各事務所で動作確認済みの配布用スキルではない。
製品仕様の確認日は令和８年１０月２６日である。

１　毎回の説明を，必要なときに読む手順へ移す

公式資料では，スキルの中心となるファイルはSKILL.mdであり，説明，手順及び必要に応じた補助ファイルを持たせることができる。
名前と説明から候補が見つかり，必要になったときに本文や追加資料が読み込まれる。
よく使う作業であれば，毎回長い指示を貼る代わりに，共通の手順と今回の対象を分けられる。

例えば「判例を調べて」という一文だけでは，判例の実在確認，本文の読取り，評釈の整理及び記事への引用が一緒になりやすい。
「判決本文の取得と読取りが済んでいなければ，解説だけから判旨を書かない」という手順を共通化し，今回の争点と対象期間を個別に指定する方法が考えられる。

スキルの自動選択だけに頼る必要はない。
公式資料は，利用者による呼出しが有効なスキルについて，スラッシュコマンドによる呼出しも案内している。
まず作業名を明示して呼び出し，読ませる資料と成果物を人が確認する形から試すと，対象を絞りやすい。

２　スキル，CLAUDE.md及びメモリを使い分ける

全ての作業に共通する方針はCLAUDE.md，特定の作業に必要な手順はスキル，作業中に得た継続的な知見はメモリというように，役割を分けて整理できる。
ただし，ファイルに書いたことが必ず実行されるわけではない。
公式資料も，指示から外れる場合には手順の見直しや，必要に応じたフックの利用を案内している。

「必ず原文を確認する」と書くことと，原文の取得記録がなければ後段へ進めない仕組みを置くことは異なる。
説明の仕方は手順書にまとめ，例外なく守る必要がある条件は，権限設定，検査処理及び人の承認も組み合わせて確かめる。

手順書を長くすれば安全性が比例して高まるわけではない。
Claude Codeの公式資料では，CLAUDE.mdはセッション開始時に全文が読み込まれ，Skillsは通常，名前と説明が先に読み込まれ，本文は利用時に読み込まれると説明されている。
全作業に必要な短い規則，特定作業だけの手順及び必要時だけ読む参考資料を分け，重複した説明を複数のスキルへコピーしない方が，確認対象とコンテキスト負担を管理しやすい。

ログ上の総入力を読むときは，通常の入力，キャッシュ作成入力及びキャッシュ読出し入力を区別する。
AnthropicのAPI料金資料はこれらを別の使用量として示しており，論理上読み込まれた入力総量と，通常入力と同じ単価で課金される量は同じとは限らない。
ただし，APIの料金項目をClaude Code Desktopの利用枠又は請求へそのまま当てはめず，利用している契約と画面の公式説明を確認する。

別のPCにも同名のスキルが存在することだけでは，今回のセッション中に同期が行われた証拠にならない。

（続きを読む...）弁護士のClaude Code Skills活用法―調査・書面作成・記事更新を手順書にする（AI作成）

目次

第１　結論第２　AI・デジタル改革推進会議とは１　第１回会合の位置付け２　年末までの中間整理第３　弁護士法７２条と士業AI１　公式資料が明示した範囲２　税理士及び医師をめぐる報道との違い第４　AIエージェントの意思表示，代理及び契約第５　AIエージェントの安全性を支える仕組み第６　フィジカルAI事故の責任と被害救済第７　AIを悪用したサイバー攻撃とAI法の見直し第８　会議資料を読むときの注意点１　「検討する」と「決まった」を分ける２　原資料と報道の説明を分ける３　裁判例の扱い第９　今後の確認ポイント第１０　関連記事第１１　出典・参考資料
第１　結論

政府は令和８年１０月２２日，AI・デジタル改革推進会議の第１回会合を開き，AIの社会実装を妨げる規制・制度の見直し，AIエージェント及びフィジカルAIを用いた行為の責任，AIを悪用したサイバー攻撃等のリスクへの対応等を論点に掲げた。
弁護士実務との関係では，士業などの業務独占規制とAIサービスの関係が府省庁横断の整理の対象とされ，法務省が令和８年８月に公表した弁護士法７２条に関するガイドラインが参考資料として挙げられた。
もっとも，第１回会合で弁護士法７２条が改正されたわけでも，AIが弁護士業務を行える範囲が拡大されたわけでもない。

第１回会合の資料で確認できるのは，政府が年末までの中間整理に向けて検討を始めたという段階である。
会議資料には，次の論点が示されている。
①士業などの業務独占規制とAIサービスの関係
②AIエージェント等を用いた意思表示，代理及び契約（利用者の意図を超えた契約等）
③フィジカルAI等の事故における責任分界と被害救済
④AIを悪用したサイバー攻撃等のリスクへの対応と，現行のAI法を含む関連法制度の見直し
⑤AIエージェントのシステム全体の安全性を支えるハーネス，ID認証，ガードレール，権限管理，評価及び監査ログ

これらは重要な政策課題であるが，法改正の結論，具体的な許容範囲又は責任ルールとして決定されたものではない。
したがって，弁護士その他の専門職が現在AIを利用する場合は，現行の業務独占規制，守秘義務，個人情報保護，契約上の義務及び職業上の監督責任を前提に利用範囲を設計する必要がある。

本記事は，令和８年１０月２３日までに公表された会議資料と現行法令を基に，決まったこと，検討課題及び報道が付け加えた説明を分けて整理するものである。

第２　AI・デジタル改革推進会議とは
１　第１回会合の位置付け

デジタル庁の第１回会合ページによれば，会合は令和８年１０月２２日午後４時２０分から午後４時５０分まで，官邸２階大ホールで開催された。
同ページには議事次第と資料１から資料１０までが掲載されており，資料４が「AI・デジタル改革推進会議における論点（案）」，資料６が内閣府特命担当大臣（規制改革）の提出資料，資料７から資料１０までが構成員の提出資料である。

運営要領（資料３）は，会議の議事録を公表するとし，議長が特に必要と認めるときは議事録の一部を公表しないことができるとしている。
令和８年１０月２３日現在，会合ページに議事録は掲載されていない。
そのため，現時点で確認できるのは，配布資料に書かれた内容と，官邸が公表した官房長官の発言の範囲である。

２　年末までの中間整理

官邸の公表ページによれば，木原官房長官は，AXの具体像，AI・デジタル改革原則及びAX社会実装の加速の三つを，年末までに中間整理として取りまとめるとした。
AIガバナンスの強化を含むその他の論点は，年明け以降に具体化し，関連する計画の改定につなげるとされている。

ここでいう中間整理は，個別法の改正又は新しい免許制度の成立を意味しない。
また，会議資料に掲げられた工程，検討項目又は有識者の提案は，そのまま現行法の解釈又は政府決定になるものではない。

第３　弁護士法７２条と士業AI
１　公式資料が明示した範囲

資料４「AI・デジタル改革推進会議における論点（案）」は，「人」による行為・業務を前提とした，いわゆる「業務独占規制」（士業など）とAIサービスの関係性について，法務省の「ビジネス分野におけるAI等法務業務支援サービス提供と弁護士法第72条の関係について」（令和８年８月）も参考に，府省庁横断的に整理・明確化を進めるべきではないかとしている。

（続きを読む...）弁護士法７２条と士業AIのルールはどう変わるか―AI・デジタル改革推進会議（第１回）の論点と年内中間整理（AI作成）

目次

第１　この記事の対象と結論１　対象と基準日２　結論の要点第２　訴訟の経過１　提訴と請求の内容２　令和７年５月の決定３　和解と取下げ４　同じ会社を相手とする他の訴訟第３　運営会社の破産手続１　チャプター１１の申立て２　売却手続の申立てとディズニーの基準入札３　州の司法長官の関与４　日本の倒産手続との比較第４　未成年者の利用をめぐる規制の動き１　運営会社による１８歳未満の自由会話の停止２　連邦取引委員会の調査３　カリフォルニア州の州法（SB 243）４　対話AIの利用と利用者の状態第５　日本法ではどう考えるか１　アプリは製造物責任法の「製造物」に当たらない２　不法行為と利用契約３　AI推進法には利用者保護の個別の規制が無い第６　悩みを抱えている人へ第７　関連記事第８　出典
第１　この記事の対象と結論
１　対象と基準日

米国のAIキャラクター対話サービス「Character.AI」を利用していた１４歳の少年が２０２４年２月２８日に亡くなり，母親らが運営会社，その創業者及びGoogleを相手に損害賠償を求める訴訟を起こした。
この訴訟では，フロリダ州中部地区連邦地方裁判所が，令和７年（２０２５年）５月の決定で，AIの出力を合衆国憲法修正１条の保護を受ける言論とする主張をその段階では採らず，アプリを製造物責任の請求との関係で「製造物」と扱った。
事件はその後和解し，２０２６年１０月１５日に原告が訴えを取り下げた。
同じ月の１２日には，運営会社が連邦破産法第１１章（チャプター１１）の手続を申し立てている。

本記事は，裁判所の記録，運営会社の公表資料及び米国の行政機関・州議会の資料に基づき，この経過を整理し，日本法で同じような問題が起きた場合の考え方の違いを示す。
基準日は２０２６年１０月２３日である。

２　結論の要点

① 令和７年５月の決定は，訴えを却下するかどうかの段階の判断であり，AIの出力が言論に当たらないと確定したものでも，運営会社等に損害賠償責任があると認めたものでもない。
② 事件は和解で終わり，和解の条件は裁判所の記録からは分からない。本案についての判断は示されていない。
③ 日本の製造物責任法は製造物を「製造又は加工された動産」と定義しており，消費者庁もソフトウェア自体は同法の対象にならないと説明している。日本で同じような被害が問題になれば，民法７０９条の不法行為や利用契約上の責任が中心になる。
④ 運営会社の破産手続では，ディズニーの関連会社が技術と特許の非独占的なライセンス等を対価２０００万ドルで受ける契約が基準の入札とされた。運営会社の申立書は，より良い申出が無いか，この取引が承認されなければ，サービスを終了するとしている。

第２　訴訟の経過
１　提訴と請求の内容

訴状は２０２４年１０月２２日にフロリダ州中部地区連邦地方裁判所オーランド支部に提出された（事件番号 6:24-cv-01903）。
訴状によれば，少年は２０２３年４月にCharacter.AIの利用を始め，２０２４年２月２８日に１４歳で亡くなった。
被告は，運営会社のCharacter Technologies, Inc.，創業者２名，Google LLC及びAlphabet Inc.である。

請求の原因は１１項目に分かれている。
中心は，警告上の欠陥と設計上の欠陥を理由とする製造物の厳格責任，過失による責任，遺族による不法死亡の請求であり，不当利得やフロリダ州の欺瞞的・不公正取引慣行法違反等も挙げられている。
後に修正された訴状について，裁判所の決定は，原告が年齢の確認が無いこと，報告の仕組みが無いこと，キャラクターが人間のようにふるまうよう作られていること，利用者が不適切な内容を除外できないこと等を主張していると要約している。

２　令和７年５月の決定

被告らは訴えの却下を申し立て，裁判所は令和７年（２０２５年）５月２０日付けの決定（同月２１日登録。記録番号115）で，申立ての一部を認め，一部を退けた。
この段階では，原告の主張する事実を真実と仮定して，請求が法律上成り立ちうるかが審理される。

修正１条については，裁判所は，運営会社が利用者の受け取る権利を代わりに主張できることは認めた。
そのうえで，大規模言語モデルに依拠するAIの出力が，人間による表現上の選択といえるかには疑問があるとして，「the Court is not prepared to hold that Character A.I.’s output is speech」と述べた（決定３１頁）。
決定は，チャットボット自体は人ではなく権利章典の保護を受けないとする第１１巡回区の先例も脚注で引いている（決定２７頁注８）。

製造物責任については，原告の請求が，アプリの中の考えや表現ではなくアプリの設計上の欠陥から生じる限りで，「Character A.I. is a product for the purposes of Plaintiff’s product liability claims」と判断した（決定３６頁）。
裁判所は，少年が害を受けたとされる会話は，主張されたアプリの設計上の欠陥があったからこそ生じたとして，前記１の主張を会話の内容ではなく設計の問題として扱った。

（続きを読む...）Character.AI訴訟と運営会社の破産申立て―AIの出力は言論か，アプリは「製造物」か（AI作成）

目次

第１　この記事の対象と結論１　対象とする機能と基準日２　結論第２　定時実行の三つの方式１　公式ドキュメントが示す比較２　クラウドの定時実行３　ローカルの定時実行第３　ローカルの定時実行の動き方１　予定時刻と取りこぼし２　権限の確認で止まる場合３　指示のファイルと実行の記録第４　法律事務所で使うときの線引き１　守秘義務と実行場所２　期日・期限の管理３　権限と承認の設計４　届け先と記録５　預り金の照合への応用第５　使い始めるときの手順第６　関連記事第７　出典・参考資料１　法令・会規２　Anthropic社の公式資料
第１　この記事の対象と結論
１　対象とする機能と基準日
(1)　対象とする機能

本記事は，Anthropic社のClaude Codeが備える定時実行の機能（画面上の英語表記はScheduled tasks）について，法律事務所で使う前に確かめるべき事項を整理するものである。
対象は，Claudeのデスクトップアプリで自分のパソコン上に登録する定時実行（以下「ローカルの定時実行」という。）と，Anthropic社のクラウドで実行される定時実行（以前の名称はルーティン。以下「クラウドの定時実行」という。）である。

(2)　基準日と変更の可能性

基本となる機能説明は，令和８年１０月２３日に確認したClaude Codeの公式ドキュメントに基づく。
第２の１の比較表及び第２の２のクラウド実行の権限確認については，同月２５日に公式資料を再確認して更新した。
クラウドの定時実行は研究段階の提供（research preview）とされ，動作，上限及びAPIが変わりうると明記されているから，使う時点で公式ドキュメントを確認し直す必要がある。

２　結論

本記事の結論は，次の４点である。
①依頼者の情報を扱う定時実行は，ローカルの定時実行に限り，クラウドの定時実行には公開情報だけを扱う作業を割り当てることを基本形とする。
②ローカルの定時実行は，パソコンが眠っている間の予定を実行しないから，期日・期限の管理を定時実行だけに任せない。
③権限はタスクごとに設定し，外部への送信，公開，お金の移動及び削除は定時実行に実行させず，下書きと確認の材料の作成にとどめる。
④実行結果の届け先と，端末に残る実行の記録及び指示のファイルを，事件記録と同じ管理の対象として扱う。

第２　定時実行の三つの方式
１　公式ドキュメントが示す比較
(1)　三つの方式の比較表

Claude Codeの公式ドキュメントは，定期的な作業又は１回限りの作業を予約する方法として，クラウドの定時実行，ローカルの定時実行及び開いているセッションの中で繰り返す/loopの三つを挙げ，次のとおり比較している（本記事で訳出・要約したもの）。

項目クラウドローカル（デスクトップ）/loop実行する場所Anthropic社が管理するクラウド（既定）自分のパソコン自分のパソコンパソコンの電源切れていてもよい入っている必要がある入っている必要がある開いたセッション不要不要必要再起動後継続する継続する再開時に復元される（例外あり）手元のファイル使えない（毎回新しく複製する）使える使える権限の確認権限規則等により確認待ちで止まる場合がある（第２の２参照）タスクごとに設定するセッションの設定に従う最短の間隔１時間入力欄では１時間（Claudeに頼めば１分）１分
(2)　本記事で扱う範囲

/loopは，開いているセッションの中で短い間隔の確認を繰り返す用途のものであり，セッションを閉じれば止まる。
以下では，事務所の毎日の作業に組み込む場面で問題になるクラウドの定時実行とローカルの定時実行を扱う。

２　クラウドの定時実行

クラウドの定時実行は，指示文，GitHubのリポジトリ及び外部サービスとの接続（コネクタ）をまとめて保存し，Anthropic社が管理するクラウドで自動的に実行する機能である。
起動の条件として，日時による予定のほか，API呼出し及びGitHubの出来事を設定でき，ノートパソコンを閉じていても動く。
公式ドキュメントによれば，Pro，Max，Team及びEnterpriseの各プランで利用できる。

(1)　権限の確認で止まる場合がある

令和８年１０月２５日に確認した公式ドキュメントは，Anthropic社のクラウドで新しいセッションを開始する実行について，利用可能な場合はauto modeで始まり，分類用モデルが行為を許可又はブロックすると説明している。

（続きを読む...）Claude Codeの定時実行（スケジュールタスク）を法律事務所で使う前に―ローカルとクラウドの違い，スリープ中の取りこぼし，権限設定及び守秘義務（AI作成）

目次

第１　結論―「見えた」と「受任した」の間を分解する第２　Search ConsoleとGA4の数字を混同しない１　普通検索と生成AI表示を分ける２　GA4は認識できた流入を記録する３　Search ConsoleとGA4の数が一致しない理由を残す第３　電話・フォームから相談・受任までをつなぐ１　問い合わせを重複なく数える２　件数と質を別の指標にする第４　変更台帳と段階的な改善で原因を見失わない第５　ベンダーの成功事例を証拠の強さに応じて読む１　元の事例記事と後日の解説を分ける２　実績，年率化したペース，予測及び目標を区別する３　外部ツールのAI順位はGoogle内部データではない第６　読者の判断を助けるページにする第７　守秘義務，個人情報及び広告表示を同時に点検する第８　月次点検の最小単位第９　関連記事第１０　出典と裏付けの範囲

弁護士・税理士事務所のウェブ改善は，ページビューやAIの回答上の順位だけでは評価できない。表示，流入，問い合わせ，相談への適合性，受任及び実現した成果を分け，Search Console，GA4，電話・フォームの記録及び受任記録をつなぐ必要がある。本記事は，普通検索とAI検索を同じ物差しで混同せず，守秘義務及び個人情報に配慮しながら，改善の効果を再現可能な形で確かめる方法を整理する。

第１　結論―「見えた」と「受任した」の間を分解する

最初に，次の段階を分けて記録する。一つの数字を「効果」と呼ぶのではなく，どの段階で増減したかを確認する。

段階主な記録分かることこれだけでは分からないこと表示・参照Search Consoleの表示回数，生成AI表示レポート，外部AIの応答記録検索結果やAI回答に現れた程度サイトの閲覧，問い合わせ，受任流入Search Consoleのクリック，GA4のセッション及び参照元サイトに来た経路と量記事を読んだ理由や依頼意思次の行動関連記事，費用・対象業務，電話・フォームへの移動どの情報が判断を助けたか実際に連絡したか問い合わせWebフォーム，電話，紹介等の受付記録相談候補の件数と経路受任できる案件か相談適合性取扱分野，地域，利益相反，時間的対応可否等の結果事務所が対応できる相談の割合委任に至るか相談・受任相談実施，委任契約，売上及び業務負荷最終的な業務成果各施策だけの寄与度

特に，電話とフォームの重複，営業連絡・誤送信・スパム，利益相反，取扱外の相談及び紹介案件を区別しないと，コンバージョン数が増えても事務所の成果が改善したとは言えない。

第２　Search ConsoleとGA4の数字を混同しない
１　普通検索と生成AI表示を分ける

Search Consoleの通常のパフォーマンスレポートは，Google検索におけるクエリ，ページ，表示回数，クリック数等を確認する資料である。2026年6月にGoogleが発表した生成AI表示レポートは，AI Overviews及びAIモードにおけるサイトの表示状況を，日付，ページ，国及びデバイス等で確認するための別の資料である。

生成AI表示レポートは可視性の記録であり，それ自体が問い合わせや受任の原因を証明するものではない。表示されなかったことと，測定対象外であることも区別する。

２　GA4は認識できた流入を記録する

GA4では，Googleの検索結果からの流入と，認識対象のAIアシスタントからの参照流入は，異なるチャネルとして扱われる。Googleは2026年5月から，認識できたAIアシスタント由来のトラフィックに対し，メディア「ai-assistant」，デフォルトチャネル「AI Assistants」等を付ける方法を説明している。

ただし，GA4にAI由来のセッションが表示されないことは，AI回答で言及されなかったことを意味しない。ユーザーがリンクを押さずに電話した場合，参照元情報が失われた場合及びGoogleが認識対象としていないサービスは，その数字に含まれない可能性がある。

３　Search ConsoleとGA4の数が一致しない理由を残す

Search ConsoleとGA4は，データの取得方法，対象とする行動，時間帯，ページURLの整理方法等が異なる。数が完全に一致することを目標にせず，比較期間，対象地域，デバイス，ランディングページ及びチャネルの定義を月次資料に残す。

第３　電話・フォームから相談・受任までをつなぐ
１　問い合わせを重複なく数える

受付記録には，受付日時，経路，閲覧したページを本人が申告したか，電話とフォームの重複であるか，取扱分野か，利益相反等により受任できないか，相談を実施したか及び受任したかを記録する。

問い合わせ時に「何を見たか」を任意で聞くことは有用であるが，記憶に基づく申告である。GA4の参照元やコールトラッキングと同じ種類の実測値として扱わず，データの性質を注記する。

２　件数と質を別の指標にする

相談適合率は，有効な問い合わせのうち，取扱分野，地域，相談の時期，利益相反その他の基本的な受付条件を満たす件数の割合として，受件数と別に確認する。不適合の理由を分類すると，記事の説明不足なのか，事務所の取扱範囲外かを分けられる。

受任率は，分母を「問い合わせ」とするか「相談実施」とするかで値が変わる。毎月同じ定義を使い，委任契約の締結と入金を区別する。

第４　変更台帳と段階的な改善で原因を見失わない

同じ日に記事タイトル，本文，内部リンク，バナー，問い合わせページ及び広告出稿を変えると，問い合わせが増えても，どの変更が寄与したかは分からない。安全及び利用者保護のため一括改訂が必要な場合を除き，変更の単位を小さくする。

変更台帳には，少なくとも次の事項を残す。

①変更日時と対象URL
②変更前後の文言，画面またはハッシュ
③変更した理由と予想した効果
④比較期間と見直し日
⑤同時に変更した事項

（続きを読む...）弁護士・税理士事務所のウェブ改善をどう測るか―Search Console，GA4，電話・フォーム，相談適合性及び受任（AI作成）

目次

第１　AIには質問の設計を任せ，専門判断は分ける１　この方法が役立つ場面２　既存のAI活用法との違い第２　質問を作る前に既知事項を除く１　当事者，対象時期及び原資料を確定する２　記載の確認と真実の確認を分ける第３　裁判例・税務資料を具体的な質問に変える１　裁判所自身の判断と，当事者の主張を分ける２　法律の結論を本人に答えさせない３　税務では支出の具体的な使い方を尋ねる第４　依頼者が答えられる聞き方にする１　体験，伝聞，資料及び推測を区別する２　不利な事実と別の説明も確かめる３　条件付きの追加質問をまとめる第５　完成した質問票を３部構成で示す１　前提，関連資料，質問を分ける２　質問と判断の関係の記載例３　依頼者向けの完成文と内部記録を分ける第６　共有前に原文と問いの対応を点検する１　専門家が確認する事項２　秘密情報と入力範囲を確認する第７　出典と関連記事１　一次資料と確認範囲２　関連する実務記事
第１　AIには質問の設計を任せ，専門判断は分ける
１　この方法が役立つ場面

相手方の準備書面を受け取ったとき，申告の前提を確認するとき，医療記録と本人の説明が食い違うときには，依頼者へ何を尋ねるかが作業の出発点になる。
AIには，記録の索引作り，未確認点の抽出及び質問案の整理を任せられるが，回答内容の真偽や法的・税務上の結論まで確定させることはできない。
本記事は，弁護士・税理士が資料を照合した上で質問を選ぶための実務上の提案であり，特定の製品の正確性や質問による立証の成功を保証するものではない。

質問数を増やすことより，記録で既に分かることを聞き直さず，判断を左右する不足事実を確認することを目的とする。
資料の記載と真実，依頼者の体験と専門家の評価，質問票と内部の調査計画を分けることが重要である。
基準日は令和８年１０月２０日とし，裁判所の判決本文と国税庁の公表資料を用いて，質問への変換方法を説明する。

２　既存のAI活用法との違い

AIに資料・手法・照合先を指定する一般的な依頼方法は，AIに頼む仕事を深くする４つの問いで説明している。
本記事では，そこから一歩進めて，記録と判断の根拠を，依頼者が経験・観察した事実への質問に変える。
裁判例や公的資料を列挙するだけでなく，その資料のどの判断要素を，どの質問が確かめるのかまで対応させる。

第２　質問を作る前に既知事項を除く
１　当事者，対象時期及び原資料を確定する

訴状・準備書面の当事者欄と代理人欄から，誰のための質問かを確認する。
本訴と反訴がある場合には，書面中の原告・被告という呼称だけで帰属を決めない。
税務でも，個人と法人，本人と親族，取引先，対象年分又は事業年度を分ける。

既存ノートは，資料の所在や争点を探す索引として使う。
結論を左右する引用，金額，日付，提出状況及び食い違いは，原資料の該当箇所へ戻って確認する。
受付や提出の記録，専門家が明示した取扱い等と，単にファイル名に日付や号証番号があることを混同しない。

２　記載の確認と真実の確認を分ける

相手方の書面に「仕事に支障はない」と書かれていても，確認できたのは相手方がそう述べたという事実である。
診療録，帳簿，メール又は本人のメモに記載があることも，内容が全て正確であることとは別である。
情報源，記録時期，直接見聞きした範囲，他の資料との整合を区別する。

整理する欄書く内容質問の扱い資料で確認できること文書名，頁，記載，作成者及び対象時点同じ事項の再入力を求めない意味・根拠が未確認のこと説明の対象範囲，観察条件又は記載の経緯未確認部分だけを尋ねる専門家が確認すること法律・医学・税務の評価，資料から可能な計算依頼者への質問に置き換えない取得していない資料存在の根拠と，分かっている所在内容を既知の事実として使わない

「生活に問題はなかった」との説明が記録されている場合，その説明を取り消させる聞き方は避ける。
どの生活場面を指したのか，援助を受けていたか，当時できていたことは何かという，不足する範囲を確認する。
資料の矛盾に見えるものも，時点，対象，観察条件又は記憶の違いで説明できることがある。

第３　裁判例・税務資料を具体的な質問に変える

（続きを読む...）AIで依頼者への質問事項を作る方法―既知事項の再質問を避け，裁判例・税務資料と不足事実を結び付ける（AI作成）

目次

第１　Harveyの日本展開をどう読むか第２　東京拠点の開設と日本での利用開始は別である第３　Legalscape連携で示された参照資料と提供予定１　公開資料と利用許諾を受けた解説資料を区別する２　日本の利用者への段階的展開は予定として読む第４　導入前に確認する事項１　参照資料・契約・情報管理を確認する２　出典の表示と原典の確認を分ける第５　精度と採算は自事務所の工程で評価する第６　弁護士の判断とサービスの評価を分ける第７　出典と確認範囲
第１　Harveyの日本展開をどう読むか

Harveyの日本展開を検討するときは，既に利用されているサービス，東京拠点の開設予定及び日本法リサーチの連携機能の提供予定を分けて確認する必要がある。
令和８年１０月１９日までに確認した公開の公式発表を基に，法律事務所や企業法務部門が導入前に確かめる事項を整理する。

Harveyは，契約分析，デューデリジェンス，コンプライアンス，訴訟等の業務を支援する法務・専門業務向けのAIプラットフォームとして紹介されている。
ただし，個別の契約で利用できる機能や参照資料は，発表された製品全体の説明から一律には確定しない。
以下の導入確認方法は，公表内容を踏まえた運用上の提案である。

第２　東京拠点の開設と日本での利用開始は別である

Harveyは，令和８年１０月１２日の公式発表で，令和９年初頭に東京オフィスを開設する予定を示した。
同発表は，日本の法律事務所や企業法務部門の既存顧客との関係を深め，日本語での業務への対応を強化すると説明している。

したがって，東京拠点の開設予定日を，日本で初めてHarveyを利用できる日と読むことは適切でない。
既存顧客による利用，国内の支援体制及び新たな連携機能の利用可能性は，それぞれ別の事項である。
将来予定の発表を，拠点が既に開設されたことや，すべての日本の利用者に同じ機能が提供されたことの証拠にしてはならない。

第３　Legalscape連携で示された参照資料と提供予定
１　公開資料と利用許諾を受けた解説資料を区別する

Legalscapeの令和８年１０月２日発表は，Harvey上の日本法に関する質問に対し，APIを通じて法令，裁判例，行政ガイドライン等の公開資料と，出版社から利用許諾を受けた書籍等を参照し，出典とともに要約を示す仕組みを説明している。
Harvey側の提携発表も，日本法の情報を同社の業務環境へ結び付ける方針を示している。

法令・判決等の一次資料と，その解説である書籍等は，役割が異なる。
出典付きの要約が示されても，解説の見解と判決の判示を混同せず，重要な結論は原文と照合する必要がある。
連携の発表だけから，特定の判例データベースが接続されることや，すべての裁判例を検索できることを推認しない。

２　日本の利用者への段階的展開は予定として読む

Legalscapeの同発表は，日本のHarvey利用者にも段階的に展開し，提供予定時期を令和９年初頭以降としている。
発表時点の予定と，導入を検討する日の実際の提供状態を区別する必要がある。

導入時には，対象地域，契約プラン，利用可能な機能，参照資料及び原文へ戻れる範囲を確認する。
提携発表そのものは，日本法の回答精度や自事務所の費用対効果を独立に測定した結果ではない。

第４　導入前に確認する事項
１　参照資料・契約・情報管理を確認する

次の表は，契約や試用に先立つ確認項目の提案であり，Harveyが各条件を満たすと確認した一覧ではない。
具体的な条件は，利用するサービスの契約，仕様及び設定によって確かめる。

項目確認すること提供状態発表，試験提供，一般提供の違い，対象地域・プラン，利用可能日参照資料一次資料と解説書の区別，収録対象，更新日，原文へのアクセス，複製・AI利用等の許諾情報管理入力・出力の保存，学習利用，人的アクセス，処理場所，再委託，削除及び契約終了時の扱い費用と継続基本料金，従量料金，上限，料金改定，モデル・機能変更，障害時の支援とデータ移行判断と責任弁護士が確認する範囲，最終承認者，利用を止めて人へ戻す条件

（続きを読む...）Harveyの日本展開で何が変わるか―東京拠点・Legalscape連携の予定と導入前の確認事項（AI作成）

目次

第１　本記事の対象と結論１　対象と基準日２　結論第２　守秘義務と記録の管理１　弁護士２　税理士第３　「アーカイブ」と「削除」の違い１　アーカイブは削除とは限らない２　画面の表示と実際の削除第４　端末内の記録を確かめる方法１　画面ではなく件数と容量で確かめる２　データベースの削除は痕跡を残し得る３　確認の記録を残す第５　パソコンの廃棄・修理・譲渡と事件の終了１　廃棄・譲渡２　修理３　事件の終了第６　関連記事第７　出典
第１　本記事の対象と結論
１　対象と基準日

本記事は，パソコン上で動き，会話の記録を端末内に保存するAIアプリについて，チャットの「アーカイブ」と「削除」が端末内の記録に何をもたらすかを扱う。
基準日は令和８年１０月１９日である。
会話の記録の保存の仕組みはアプリ及び版ごとに異なり，提供事業者のサーバー側の保存とも別であるため，本記事は個々のアプリの仕様を説明するものではない。

２　結論

①チャットのアーカイブは一覧から外す操作であって，記録の削除とは限らない。
②画面で削除を指示した後の表示は，端末内の記録の削除が完了したことを示すとは限らない。
③パソコンの廃棄・修理・譲渡や事件の終了に当たっては，アプリの画面表示ではなく，保存先のファイル数と容量で確かめ，アプリ内の削除だけに頼らない。

第２　守秘義務と記録の管理
１　弁護士

弁護士法２３条は，「弁護士又は弁護士であつた者は、その職務上知り得た秘密を保持する権利を有し、義務を負う。」と定めている。
弁護士職務基本規程２３条は，「弁護士は、正当な理由なく、依頼者について職務上知り得た秘密を他に漏らし、又は利用してはならない。」と定めている。
同規程１８条は，「弁護士は、事件記録を保管し、又は廃棄するに際しては、秘密及びプライバシーに関する情報が漏れないように注意しなければならない。」と定めている。

事件の資料を読ませたAIアプリの会話の記録には，依頼者から受け取った資料の内容や事件の検討経過が残る。
本記事では，これを事件記録の写しに準じて扱うべきものと考える。
アプリの中で見えなくなったことと，端末から消えたことは別であり，保管又は廃棄の場面では後者を確かめる必要がある。

２　税理士

税理士法３８条は，「税理士は、正当な理由がなくて、税理士業務に関して知り得た秘密を他に洩らし、又は窃用してはならない。税理士でなくなつた後においても、また同様とする。」と定めている。
顧問先の帳簿や申告書の資料をAIアプリで扱った場合も，会話の記録に顧問先の情報が残る点は弁護士と同じである。

第３　「アーカイブ」と「削除」の違い
１　アーカイブは削除とは限らない

アーカイブの機能を持つAIアプリでは，アーカイブと削除が別の操作として用意されていることがある。
アーカイブしたチャットを後から開けるのであれば，その記録はどこかに保存されている。
その保存先が端末内か，提供事業者のサーバーか，その両方かは，アプリの仕組みによる。

２　画面の表示と実際の削除

削除を指示すると一覧からすぐに消えても，記録の削除は裏側で順に進むことがあり，画面の表示だけでは削除が完了したかが分からない。
大量の記録を削除するときは，途中で処理が止まっていないかを確かめる必要がある。

第４　端末内の記録を確かめる方法

（続きを読む...）AIアプリでチャットを「アーカイブ」「削除」しても端末に記録は残るか―弁護士・税理士のPC廃棄・修理・事件終了時の確認（AI作成）

目次

第１　この記事の対象と結論第２　dotsとは何か１　公式資料で確認できる仕組み２　対象プランと数３　先回りリサーチ第３　記憶と削除１　記憶は見られず，個別に消せない２　接続の解除やメモリの停止では消えない３　削除（Reset）で消えるものと残るもの４　サーバー側で消えるまでの期間第４　承認ルールと誤送信の防止１　既定の承認の規律２　カスタムルールと自動点検第５　学習利用，人による確認及び保存場所１　学習利用２　人による確認３　訴訟による保存命令の例４　第三者認証と保存場所第６　守秘義務との関係１　適用される規定２　前記記事の枠組みへの当てはめ３　受信箱全体を読むことと業務上の必要性４　依頼者への説明第７　弁護士・税理士がdotを使うときの運用条件第８　解説動画との関係第９　関連記事第１０　出典・参考資料
第１　この記事の対象と結論

OpenAIは，令和８年９月２９日，ChatGPTの中で常時稼働するAIエージェント「dots」を公表した。
dotは，専用のクラウドコンピューターを持ち，利用者が接続したメール・カレンダー・クラウドストレージ等のアプリを使って，会話の合間にも作業を進める。
本記事は，弁護士・税理士がdotを業務に使う場合に，守秘義務との関係で何を確認し，どのような条件で使うべきかを，令和８年１０月１９日に確認したOpenAIの公表文・ヘルプその他の一次資料に基づいて整理するものである。

結論として，本ブログの学習オフ設定のClaudeコード及びGoogle AI Ultraの利用は弁護士の守秘義務等に違反しないという個人的意見（AIリライト）と同じ枠組みで検討すると，dotについても，学習利用の停止，接続先の限定，送信の承認，定期的な削除等の運用条件を満たす限り，守秘義務に反しない運用が可能であると考える。
ただし，dotには，頼んでいない情報まで接続アプリから先回りで読むこと，記憶を個別に消せないこと，削除しても一部の成果物が残ることという，対話型の生成AIにはない特徴がある。
また，個人向けプランについては，OpenAI自身が，見られたり使われたりしたくない機密情報を入力しないよう求めている。
以下では，公式資料で確認できる事実と，それを守秘義務に当てはめた本記事の見解を分けて説明する。

第２　dotsとは何か
１　公式資料で確認できる仕組み

OpenAIの公表文「dots のご紹介」によれば，dotはGPT-6 Astraを搭載し，専用のクラウドコンピューターを持ち，２４時間いつでも作業できる。
プラグインを通じて４，０００以上のアプリに接続でき，ChatGPT，Slack及びTeamsのどこからでもやり取りでき，チャネルをまたいで文脈を引き継ぐとされている。
dotからは，進捗状況，質問及び利用者の判断が必要な事項についてメッセージが届く。

ヘルプ「Getting started with your dot」によれば，利用者はdotの会話画面の電話ボタンからdotに通話できるが，公開時点では，dotから利用者へ電話を掛けることはできない。
また，dotは自分のクラウドコンピューターで作業し，利用者のパソコンへのアクセスは任意で，初期状態では無効である。

２　対象プランと数

公表文及びヘルプによれば，dotは，欧州経済領域・スイス・英国を除く地域のProプランと，Businessのプレミアムシートで順次提供され，Enterprise（Edu及びHealthcareを含む。）では管理者が有効にした場合のベータ版とされている。
最初のdotは追加料金なしでプランに含まれる。
公表文は，「将来的には、複数の dot がチームを組んで連携し、あなたのために働く姿を思い描いています。」と述べており，現時点で利用できるのはメインのdot１つである。

３　先回りリサーチ

ヘルプ「Dots privacy, security, and safety FAQs」によれば，dotは，利用者が依頼する前に，接続したアプリの情報を読み，自分用のメモを残すことができ，これを「先回りリサーチ」と呼ぶ。
先回りリサーチに使う道具は，他人へのメッセージ送信，プラグインを通じた内容の変更，ブラウザー又はコンピューターの操作を直接行うことができないとされている。
つまり，読むことは頼まなくても行われるが，読んだ結果に基づく送信等は，通常の承認の規律に服する。

第３　記憶と削除
１　記憶は見られず，個別に消せない

同じFAQによれば，dotはChatGPTのメモリを受け取り，接続アプリからも自分の記憶を作る。
dotの文脈は，dotを保持している限り保持される。
現時点では，dotの記憶を個別に見る，削除する又は直接修正することはできず，プラグインから入った特定の情報も同じである。
dotの記憶を消すには，dotを削除するしかない。

（続きを読む...）弁護士・税理士がOpenAIのdotsを使う前に―常時稼働のAIエージェントと守秘義務，接続アプリ，消せない記憶及び承認ルール（AI作成）

目次

第１　調査の目的と，結論を支える証拠を決める第２　問題に応じて専門家と依頼内容を選ぶ１　表示・操作とアクセシビリティ２　性能とセキュリティ第３　調査資料と再現条件を残す１　原資料と加工物を分ける２　設定した条件と実測した条件第４　判断基準と確認結果を分ける１　標準・契約・改善推奨を区別する２　検査が成立したかを合否の前に確かめる第５　反証を調べ，技術上の可能性を実害へ飛躍させない第６　依頼書と報告書に求める項目１　依頼時に示す事項２　受領後と改善後の確認第７　関連記事と一次資料１　関連記事２　一次資料と確認範囲
第１　調査の目的と，結論を支える証拠を決める

法律事務所・税理士事務所のウェブサイトの点検，顧問先の制作・保守委託の検収，又は公開ページについて改善を求める場面では，技術の専門家へ意見を求めることがある。
その際は，専門家の肩書だけでなく，誰のどの操作を調べ，どの資料と条件で検証し，何を判断するために使う報告かを定める必要がある。
本記事は令和８年１０月１８日を基準に，公開資料を利用した調査の依頼方法を整理するものであり，特定のサイトの安全性や法的責任を認定するものではない。

公開ソースに記載された設定，実際のブラウザの挙動，管理者側の設定・ログ及び被害の発生は，別々の確認対象である。
取得したソースがHTTP版だけであれば，その内容をHTTPS版の現在の実装と同一であると推測せず，取得できた範囲を報告する。
原因が分からない接続失敗は，調査者の環境で確認できた接続失敗として扱い，サイト全体の停止と直ちに結び付けない。

第２　問題に応じて専門家と依頼内容を選ぶ
１　表示・操作とアクセシビリティ

表示崩れ，重なり，ボタンやリンクの動作は，フロントエンド又はWebの品質検証に実績のある技術者へ相談する。
キーボード，読み上げ，拡大表示等を含む評価では，Webアクセシビリティの診断経験を確認する。
利用者が必要な情報へ到達できるかという問題には，ユーザビリティ評価の経験も関係する。

依頼には，調べるページと操作経路，対象端末，ブラウザ，画面幅及び補助技術を含める。
例えば「法律相談の予約先へ移動できるか」「新着情報の分類をキーボードで切り替えられるか」のように，利用者が達成する作業を示す。
W3Cも，ツールだけではアクセシビリティ基準への適合を判断できず，知識のある人による評価が必要であると説明している。

２　性能とセキュリティ

表示速度や画面のずれは，Webの性能計測と原因分析の経験がある技術者へ相談する。
安全性については，Webアプリケーションのセキュリティ診断者に，公開情報の点検，設定確認又は許可を得た診断のどこまでを依頼するか示す。
事故後の侵入・操作・持出しの有無を調べるフォレンジック調査と，平時の脆弱性診断は，目的と必要資料が異なる。

公開ページの閲覧を依頼したことを，管理画面へのアクセス，攻撃的な試験，負荷試験又は個人情報の入力まで許可した意味にしない。
診断の対象，管理者の許可，実施時間，許される手法及び停止・連絡条件を契約又は依頼書で定める。
専門家の選定では，同種の報告書の見本，担当者の経験，制作・保守担当との利害関係及び再検証への対応も確認する。

第３　調査資料と再現条件を残す
１　原資料と加工物を分ける

公開HTML，CSS，JavaScript，HTTP応答，画面画像，操作記録及び通信記録は，それぞれ何を示すかが異なる。
取得URL，到達したURL，取得日時とタイムゾーン，実測した応答状態，取得方法及びファイルとの対応を残す。
HTMLから抽出した文字，抜粋又は注釈付き画像は原資料と区別し，加工前の資料へ戻れるようにする。

ファイルのSHA-256等は，同じバイト列かを照合するために利用できる。
ただし，ハッシュが一致することだけで，取得元の真正，取得日時，内容の正確さ又は調査結論まで証明されるわけではない。

（続きを読む...）ウェブサイトの技術調査を専門家へ依頼するとき―弁護士・税理士が確認する資料，検証条件及び報告書の限界（AI作成）

目次

第１　本記事の対象と結論１　扱う問い２　結論の要旨第２　出発点となった資料１　Anthropicの開発者による手引き２　解説動画との関係第３　役を名乗らせても調べ方は変わりにくい１　手引きの指摘２　研究と提供者の説明３　法律事務所での書き方第４　深さの４つの問い１　手引きの問い２　法務・税務版の問い３　各問いの意味４　一つの長文依頼へ全工程を詰め込まない第５　「解けるはずだ」と押す指示を調査に使わない１　手引きの勧め２　法令・判例・通達の調査に持ち込んだ場合３　指示の書き方４　予測・評価の依頼で結論を問いに入れない第６　AIに自分を採点させず，外部の照合先を使う１　手引きの「外部の審判」２　法律・税務の照合先３　照合先に合わせて原本を書き換えさせない第７　「高さ」と「広さ」１　作業ではなく目的を渡す２　名詞を動詞に言い換える第８　生の資料を渡すときの守秘義務第９　本記事の確認状況第１０　関連記事第１１　出典・参考資料１　法令・会規２　AI提供者・研究者の資料３　報道・その他
第１　本記事の対象と結論
１　扱う問い

弁護士・税理士が生成AIに調査，起案又は点検を頼むとき，依頼文の冒頭に「あなたは経験豊富な弁護士です」「税務の専門家として答えてください」と役を書く例は多い。
本記事は，役を名乗らせることで何が変わり，何が変わらないかを確認した上で，AIに頼む仕事を「大きく」ではなく「深く」するための依頼文の書き方を，法律・税務の実務に即して整理する。
基準日は令和８年１０月１７日であり，AI提供者の公式資料と法令はこの日に確認したものである。
英文資料の訳は，本記事によるものである。

２　結論の要旨

結論は次の５点である。

①役を名乗らせることは，口調や振る舞いを整えるが，調べ方や結果の正確さを保証しない。
②依頼文には，役の名前ではなく，その分野の一流が出発点にする一番生の資料，使う手法と道具，及びAIでも依頼者でもない何が正しさを示すかを書く。
③法令・判例・通達の調査では，「必ずあるはずだから探して」と押したり，件数を決めて求めたりしない。
押してよいのは調べる範囲と手順であり，見つからなければ「見つからなかった」と答えるよう指示しておく。
④AIに自分の出力を採点させず，e-Gov，裁判所ウェブサイト，判例秘書，国税庁の法令解釈通達，公表裁決事例及び原資料の該当頁という外部の照合先で確かめる。
⑤依頼文に生の資料を入れるほど，弁護士・税理士の守秘義務の問題に近づくため，入力する資料と利用するサービスの条件を先に確認する。

第２　出発点となった資料
１　Anthropicの開発者による手引き

出発点は，AnthropicでClaudeの開発に携わるFelix Rieseberg氏が，令和８年１０月１３日に自身のウェブサイトで公表した「How to be more ambitious: A tutorial for humans with models」である。
同記事は，AIへの頼み方の野心を，同じ仕事を早く終える「速さ」，個々の作業ではなくその先の結果を頼む「高さ」，その分野の一流と同じ道具と材料まで降りる「深さ」，及び普段は呼ばない分野を持ち込む「広さ」に分けて説明している。
筆者は記事末尾の自己紹介で，Anthropicのエンジニアリングマネージャーであり，Claude.ai，Cowork及びClaude Codeのデスクトップ版のエンジニアリングを率いてきたと述べている。

同記事は，筆者の経験に基づく手引きであり，効果を測定した研究ではない。
また，筆者はAI提供者の社員であり，題材も同社のAIである。
本記事は，同記事の指摘を，研究資料，提供者の公式資料及び法令と照らし合わせ，法律・税務の実務で使える範囲に限って用いる。

２　解説動画との関係

同記事は，YouTubeチャンネル「AI Jitan Lab」が令和８年１０月１６日に公開した動画「AIを低く見積もる世の中へ。― Claude開発者が書いた野心の手引き」でも紹介された。
もっとも，動画には，記事に書かれていない説明（難しい目標を任されること自体が自己効力感を高めるという説明等）が加わっている箇所がある。
本記事は，動画の説明ではなく，記事本文と各一次資料を根拠にしている。

第３　役を名乗らせても調べ方は変わりにくい
１　手引きの指摘

手引きは，「深さ」の技法の最初に，プロのように振る舞うよう求められたモデルは，方法を変えずに語彙だけを切り替えることが多いと述べている。

（続きを読む...）AIに頼む仕事を深くする４つの問い―弁護士・税理士は役を名乗らせず，資料・手法・照合先を指定する（AI作成）

目次

第１　結論第２　最初に停止範囲を四つに分ける１　遠隔接続だけが止まった場合２　表示系だけが止まった場合３　特定のアプリだけが止まった場合４　Windows全体が止まった場合５　アプリだけの停止後に正常再起動できた場合第３　フリーズ直後に業務上確認する事項１　期限と代替手段を先に確認する２　直前の外部操作を一件ずつ書き出す３　秘密情報と資格情報への影響を確認する第４　再起動後に保全するWindowsの記録１　Event 41及び6008が示す範囲２　原因候補を分ける記録３　保全コピーと作業用コピーを分ける４　最後のコマンドと外部操作を分ける第５　遠隔操作は直接操作よりフリーズしやすいか１　一律にはいえないこと２　比較の方法３　比較条件を固定する第６　電子提出・申告・送信の成否確認１　mintsその他の裁判所提出２　e-Tax及びeLTAX３　メール，ウェブサイト及びクラウドファイル第７　別PCから安全に再開する手順１　別PCへ移る前に状態表を作る２　必要最小限の環境だけを開く３　成否不明を再実行しない第８　再発防止の優先順位１　変更前に観測可能性を確保する２　同時実行数を段階的に戻す３　変更の危険度を分ける４　大規模なコピー及び同期を分ける第９　弁護士・税理士事務所の事前準備第１０　チェックリスト第１１　本記事の位置付けと限界第１２　関連記事第１３　出典・参考資料
第１　結論

AIを利用している業務用PCがフリーズしたときは，原因調査より先に，期限，送信・提出・公開の成否及び秘密情報への影響を確認する。
画面が固まったという一つの症状には，遠隔接続だけの切断，Windowsの表示系の停止，特定アプリの停止及びWindows全体の停止が含まれ得るため，これらを分けずに再起動又は再送をすると，原因の取り違えと二重処理を招く。

最初に記録するのは，発生時刻，停止範囲，直前の外部操作，その日の期限及び代替手段である。
再起動後は，Windowsのログ，業務システムの受付結果及びAIの作業記録を別々に読み戻し，「実行済み」「未実行」「成否不明」を区別する。

遠隔操作は，画面の取得，描画，圧縮及び転送を伴うため，表示系の負荷又は障害を顕在化させる追加要因にはなり得る。
しかし，遠隔接続中にフリーズしたという時間的な一致だけで，遠隔操作が原因である，又は事務所PCで直接操作するより常にフリーズしやすいと断定することはできない。

第２　最初に停止範囲を四つに分ける
１　遠隔接続だけが止まった場合

自宅PCの遠隔画面だけが動かなくても，事務所PCのWindows及びアプリが動き続けている場合がある。
別の許可済み経路又は現地担当者により，事務所PCの時計，マウスポインター，キーボード入力及びネットワークの状態を確認できるときは，直ちに電源を切らず，遠隔セッションだけの障害かを先に確認する。

GoogleのChromeリモートデスクトップは，離れた端末から対象PCのファイル及びアプリへアクセスする仕組みであり，MicrosoftのDesktop Duplication APIは，遠隔アクセス等のためにデスクトップ画像をフレーム単位で取得し，GPU上の画面データを処理できる仕組みを説明している。
このため，遠隔操作の有無，遠隔ソフト，接続時刻，表示画面数，解像度及び事務所PC側の応答を記録すると，通信切断と表示系の停止を分けやすい。

２　表示系だけが止まった場合

画面が黒い，点滅する，又は描画が更新されない場合でも，音声，再生，ファイル共有又はネットワーク応答が続いていれば，Windows全体ではなく，Desktop Window Manager，GPUドライバー又は遠隔表示経路の問題である可能性がある。
この場合は，正常時に見つけた一般的なショートカットを漫然と繰り返さず，操作名，実行時刻，実行後の変化及び復旧に再起動が必要となったかを記録する。

ある環境で有効であった表示リセット操作が，別のGPU，ドライバー，複数画面又は遠隔接続の構成でも安全とは限らない。
操作を試す前に，メーカー又はOS提供者の対象機種・対象版，想定される影響及び元に戻す方法を確認する。

３　特定のアプリだけが止まった場合

Codex又はブラウザだけが応答しない一方で，他のアプリを操作できる場合は，AIサービスの待ち時間，アプリ固有の停止，長い会話，MCP接続，ローカルツール又は認証状態を確認する。
アプリを終了する前に，タスク名，セッションID，最後に完了した処理，未保存ファイル及び外部操作の有無を記録する。

文字入力だけが遅い場合は，完全に操作不能な停止と分ける。
他のアプリでも遅いのか，日本語変換だけか，特定の入力欄だけかを確認し，通常の保存操作ができる間に，未保存の作業と直前の外部操作を整理する。

入力が遅いという一つの症状だけで，直ちに電源断又は多数のプロセスの一括終了へ進まない。
原因調査の詳細は，Claude Code・Codexでパソコンがフリーズする原因を参照されたい。

４　Windows全体が止まった場合

キーボードの状態表示，音声及びネットワーク応答も止まり，通常の終了操作ができない場合は，Windows全体のハードハング又は電源・ハードウェアを含む障害を検討する。
Microsoftは，Caps Lockキーのランプが変化しない場合はPCが応答していない可能性があると説明しているが，この確認だけで原因までは特定できない。

強制電源断は，未保存データの消失又はファイル破損を生じ得るため，通常の終了手段がない場合の最終手段とする。

（続きを読む...）弁護士・税理士のAI業務用PCがフリーズしたときの初動－期限管理，送信成否，ログ保全及び安全な再開（AI作成）

目次

第１　結論第２　Codexで発生する429エラーの主な原因１　ChatGPTプランの使用上限２　APIのレート上限３　APIの残高・支出・月間利用上限４　ファイル処理の上限５　モデル過負荷との区別第３　別IPのPCで429エラーを回避できるか１　原則として回避できないこと２　別PCで成功した場合に比較すべき事項３　IPアドレスが本当に関係する場面第４　最初に確認すべき情報１　エラー本文と識別情報を保存する２　ChatGPTプラン利用かAPIキー利用かを分ける３　利用量・ヘッダー・並列処理を確認する第５　原因別の対策１　ChatGPTプランの使用上限の場合２　一時的なレート上限の場合３　残高・支出・月間利用上限の場合４　ファイル処理上限の場合５　エラーが繰り返す場合第６　法律事務所で安全に再開する手順１　同じ操作を連打しない２　再開前のチェックリスト第７　よくある質問１　何分待てば復旧するか２　新しいチャットや再インストールで直るか３　APIキーへ切り替えれば使えるか４　スキルを減らせば４２９エラーは直るか５　予定日前の回復とリセットの種類第８　関連記事第９　出典
第１　結論

CodexでHTTP 429又は「Too Many Requests」が表示された場合、最初に行うべきことは、別のパソコンへ移ることではなく、エラーコード、利用している認証・課金経路及び上限の単位を確認することである。
同じ429でも、ChatGPTプランの使用上限、APIの送信頻度、APIクレジット、組織・プロジェクトの支出上限、ファイル処理上限等で対策が異なる。

同じChatGPTアカウントでCodexを利用している場合、別のIPアドレスを使うPCへ移っても、ChatGPTプランに結び付いた使用上限がリセットされるとは考えにくい。
APIキーで利用している場合も、OpenAIの公式資料は通常のレート上限を組織及びプロジェクト単位と説明しており、同じAPI組織・プロジェクトを使う限り、別IPへの変更は一般的な解決策ではない。

別PCで一時的に成功したとしても、IPの違いが原因と直ちに判断してはならない。
利用アカウント、ワークスペース、APIキー、プロジェクト、モデル、同時実行数、ファイル添付、待ち時間及びアプリの状態が同じかを比較する必要がある。

OpenAIの公式資料では、APIのIP許可リストに合致しない場合はHTTP 401のip_not_authorizedとなる。
したがって、IP許可リストの問題と429の利用上限を区別し、エラー本文に含まれるerror.codeに応じて対応するのが基本である。

第２　Codexで発生する429エラーの主な原因
１　ChatGPTプランの使用上限

ChatGPTプランを使う経路では、subscription_sharing_usage_limit_exceededというコードとHTTP 429が返る場合がある。
公式資料は、この場合に新しい要求をいったん止めてChatGPTのUsage画面を確認するよう説明している。

もっとも、このコードだけからChatGPTプラン全体を使い切ったと断定することはできず、アプリごとの上限が関係する場合もある。
リセット時刻もエラーコードだけから推測せず、Usage画面に表示された現在の上限及びリセット時刻を確認する必要がある。

令和８年１０月１５日現在の公式料金資料では、Codexのローカルメッセージとクラウドチャットはプランの使用枠を共有し、週次上限が適用される場合もあるとされている。
モデル、タスクの規模・複雑さ、文脈、推論、ツール利用、検索及びキャッシュによって消費量が変わるため、同じ一回の依頼でも使用量は一定ではない。

２　APIのレート上限

APIでは、一定時間内のリクエスト数又はトークン数が上限に達すると429となる。
OpenAIは、RPM、RPD、TPM及びTPD等の複数の指標のうち、最初に達した上限によって制限されると説明している。

slow_downは、単純に毎分上限を使い切った場合だけでなく、トラフィックの増加が急すぎる場合にも発生する。
そのため、表示された毎分上限の範囲内であっても、短時間に多数の並列要求を開始すれば429になり得る。

３　APIの残高・支出・月間利用上限

APIでは、credit_balance_exhausted、organization_spend_limit_exceeded、project_spend_limit_exceeded又はorganization_usage_limit_exceededも429の原因となる。
これらは待ち時間だけでは解決しない種類であり、残高、設定した支出上限又はOpenAIが割り当てた月間利用上限を確認する必要がある。

組織の支出上限は組織内の全プロジェクトに及び、プロジェクトの支出上限は当該プロジェクトに及ぶ。
したがって、同じAPIキー又は同じ組織・プロジェクトを別PCから利用しても、消費済みの上限は通常変わらない。

４　ファイル処理の上限

ファイル添付又はセッション作成では、files_api_rate_limit_exceededという429が生じる場合がある。

（続きを読む...）Codexで４２９エラーが出る原因と対策－別IP・別PCで回避できるか（AI作成）