今日の主要トピック
モデルは変わり、権限は残る。今日は運用の境界を考えた
AI透明性規範、チーム別モデル方針、npmトークン制限、エージェントの秘密情報検査を読み、新機能より交換できて止められる運用を先にしたいと思った。

Summary
ひと目でわかる要約
- AI生成物の表示は最後に付けるラベルではなく、出所と人による確認履歴を残すことだと受け止めた。
- チーム別モデル権限と実際のモデル終了を見て、モデル名を固定依存ではなく交換可能な方針として管理したいと思った。
- 自動化トークンとエージェント環境には、広い権限より短い寿命、検査、人の承認が必要だと判断した。
今朝のブリーフィングには、モデル、規制、トークン、エージェント、ブロックチェーンの話が一度に並んでいた。最初は、また新しい機能を追いかけなければならないのかと思った。それでも元の発表を一つずつ確かめると、私に残ったのは機能の一覧ではなかった。
変化の速い技術を長く使うには、何を使うかより先に、どこまで許し、どう交換するかを決める必要がある。
今日は、公式資料で確認でき、この考えに直接つながる五つだけを残した。大きな予測より、今のサービスに使える運用基準を記録したい。
AI表示は、一つのラベルだけでは足りない
OpenAIは7月31日、EUの汎用AIモデル行動規範とAI生成コンテンツ透明性行動規範を支持したと発表した。生成物の出所を残す仕組みとしてContent Credentials(C2PA)とSynthIDを併用する考えを示し、メタデータは失われることがあり、一つの信号だけでは完全ではないという限界も明記している。
私はその限界の書き方に共感した。「AIが作りました」という一文だけで責任が終わるとは言っていないからだ。後から結果をたどるには、どのモデルと道具を使い、人が何を直し、誰が公開を承認したのかまで残す必要がある。
この記事もAIの助けを借りて資料を整理し、三つの言語へ移し、表紙も記事専用に生成した。その代わり、確認した出典を主張の近くに置き、承認状態をメタデータへ残し、実際の公開は人がプルリクエストをマージした時点で確定する。完全さの証明ではないが、私が守りたい最低限の境界である。
モデル選択は、好みではなく権限と交換の問題になった
GitHubはCopilot BusinessとEnterprise向けに、エンタープライズチーム単位のモデル方針を公開プレビューとして発表した。企業全体の基準モデルを定めたうえで、特定のチームに追加モデルを許可できる。複数チームに所属する利用者は、いずれかのチームからモデルを付与されると利用できる。多くのエンタープライズ顧客には8月3日からプレビューの選択肢が順次提供される予定だ。
同じ日、GitHubはGemini 2.5 ProとGemini 3 FlashをCopilot全体で終了した。推奨される代替は、Gemini 3.1 ProのプレビューとGemini 3.6 Flashである。
二つを続けて読むと、モデルは開発者が個人的に選ぶだけの項目ではない。組織は誰がどのモデルを使えるかを決め、選んだモデルが消えた後も仕事を続けられるかを確認しなければならない。
私もHaruSpaceのコード各所に特定のモデル名を埋め込みたくない。短い作業、長い計画、コードレビューのように役割を先に定義し、実際のモデルは交換可能な設定として結び付けたい。交換前には代表的な作業で成功率、待ち時間、費用、人の修正量を比べ直す。最新モデルを早くつなぐことより、交換しても仕事が壊れないことの方が重要だ。
自動化トークンをアカウントの万能鍵にしてはいけない
npmは、二要素認証を回避する設定のgranular access tokenを制限した。このトークンでは、新しいトークンの作成・削除、パッケージのアクセス権やメンテナー、trusted publishing設定、組織・チーム構成を変更できなくなった。これらの操作には人が参加する2FA認証が必要だ。npmは2027年1月を目標に直接公開の権限もなくし、OIDCによるtrusted publishingか、人が承認するstaged publishingへの移行を案内している。
自動化は人の反復作業を減らすためのものであり、人の全権限を複製するためのものではない。配布処理には配布に必要な権限だけを、必要な時間だけ渡すべきだ。便利さのための長期トークン一つでアカウントや組織まで変更できるなら、自動化ではなくリスクを保存したことになる。
エージェントが去った場所も確認したい
Google Cloudの7月31日リリースノートでは、Agent Platform Vulnerability Assessmentのプレビューが公開された。顧客が配置したGemini Enterprise Agent Platformコンテナ内から、平文の認証情報、アクセストークン、APIキーを検出する機能である。
作業が終わったからといって、環境まできれいになったとは限らない。ログ、一時ファイル、エラー出力に機密値が残ることがある。私は作業の終了を単なる削除時点ではなく検査時点として扱いたい。短い権限を発行し、出力とファイルを調べ、トークンを失効させてから環境を消す。異常が見つかった場合には、自動で次へ進まず、人が止められる必要がある。
公開台帳は、相手の身元まで保証しない
米国財務省が7月29日に発表した内容によると、制裁対象となったイランのデジタル海上保険サービスHormuz Safeは、ビットコインと他のデジタル資産を決済手段として受け入れていた。財務省は、これを西側の制裁を回避する仕組みの一部だと説明している。
私はブロックチェーン技術に関心がある。それでも、取引が公開されていることと、相手が安全であることを同じ意味にはしたくない。アドレスと金額が見えても、実際の支配者や決済目的まで自動的に分かるわけではない。いつかHaruSpaceへウォレットや資産機能を加えるとしても、取引ボタンより先に、リスク確認、保留と審査、人が下した判断の記録が必要だと思う。
今日残した五つの質問
今日の資料を製品計画へ移すと、新機能の一覧より先に次の質問が残る。
- このモデルと道具を使えるのは誰か。
- 自動化へ渡す権限はどこまでで、いつ終わるのか。
- 作業後のログとファイルに何が残るのか。
- モデルが終了しても同じ仕事を続けられるのか。
- 外部公開や重要な実行を最後に承認するのは誰か。
AIの道具はこれからも速く変わるだろう。私はそのすべてを追いかけるより、変化しても守るべき境界を先に作りたい。モデルは消え、トークンは失効させるべきものだが、誰が決め、どこで止められたかという記録は長く残る。
今日の結論は単純だ。新しいAI機能をもう一つ追加する前に、それを止め、交換し、責任を持つ方法から作る。

