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

３　保存済みリセット

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

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

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

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

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

出典：OpenAI「How resets work in Codex」，公式料金ページ，有料週間リセット，個人プランの追加クレジット。

第３　次回の回復日時が変わる理由

（続きを読む...）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変換又は外部ツールが継続中なら，画面上は一つのセッションでも複数プロセスが動くことがある。

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

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

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

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

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

AIエージェント又はターミナルを使っていた場合は，最後に実行を開始したコマンド，対象の種類，対象範囲及び完了表示の有無を記録する。
コマンド本文に依頼者名，事件名，ファイル名又は保存先が含まれるときは，公開用のメモへそのまま写さず，機密性を保った調査記録に保存する。

ファイル検索では，ファイル名だけか内容まで検索したか，対象がローカルSSDかクラウド同期領域か，大きなPDF又は画像を含むかを区別する。

（続きを読む...）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作成）

目次

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

弁護士ドットコムの「みんなの法律相談」に投稿する前に確認したいのは，表示名だけでなく，相談本文が誰に読まれるかという点である。
運営者の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作成）

目次

第１　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作成）

目次

第１　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作成）