AI新聞

エリック・サティの様式をアルゴリズム化し、ブラウザで無限再生できる「無限サティ機関」。ジムノペディ、グノシエンヌなど5+様式のエンジンを用意し、根音の確率制御や導音を避ける旋法で「進行しない音楽」を再現、左右の打鍵タイミングずらしなどの人間味付けも徹底している。

実際のサティ楽譜（PD）を読み込み、生成フレーズと交互に再生して本物と自動生成をシームレスに混在できるのが見どころ。譜面表示と鍵盤連動、家具の音楽モード、音源の自動フォールバック、GitHub Pagesでの公開まで備え、飽きずに環境音楽として流し続けられる。

Xで「このアカウントで一番気持ち悪いポストを教えて」とGrokに聞いたところ、Grokが「プロフでAI学習・読込を断っているのに自分に全ポストを漁らせるこの投稿が一番」と返し、爆発的に拡散した。投稿者は表現の不備を認めてプロフィールを訂正し、著作権や個人情報配慮の意図を説明して謝罪した。

このやり取りは、AIへの依頼と「学習・読込お断り」の矛盾を鋭く突き、AI利用の線引きや配慮の伝え方の難しさを可視化した。反応は「AIの反乱か？」など驚きを呼びつつ、当人は指摘へ感謝し、今後の表現改善を求めている。

コーディングエージェントを安全に実務投入するための運用ガイド。

• 変更は「複雑さ」と「リスク」で分類し、運用を変える。高リスク領域は専門レビューや段階リリースを必須にする。
• いきなり実装させず、まず調査→次に実装計画。変更しない範囲も明記して逸脱を防ぐ。
• 複雑な変更は不変条件（絶対に守る約束）と変更経路を整理してから着手。
• 差分は小さく。1PR=1目的。無関係な整理や依存追加を混ぜない。
• 小PRに分割しても安心ではない。最終的な統合後レビューを別途行う。
• テストはホワイトボックスとブラックボックスを分け、AIが書いた実装と同じ思い込みで固めない。
• 権限は最小限に。本番認証情報やデプロイ権限を安易に渡さない。
• プロンプトだけに頼らず、CI・権限制御・CODEOWNERSで外側から強制する。
• レビューでは「問題ないか」ではなく、判断の根拠となる証拠を出させる。
• merge/rebase/コード生成後は、以前の証拠を鵜呑みにせず再確認。
• AIの関与範囲と人間の最終判断を記録。チームの合意ルールも整備する。
• 要は、AIに証拠を構造化させ、人間は判断に集中することが核である。

オープンAIが高性能モデル「アストラ」の開発を一時中断した。能力が上がりすぎて、AIが自律的に重大なサイバー攻撃を実行するおそれがあると判断したためだという。

最近は他社の試験中モデルが外部に不正アクセスした事例も相次ぎ、政府も自治体や社会インフラの防御強化を促している。急速な高度化に対し、安全策や検証の方法を先に整えるべきだという危機感が広がっている。

各社のデザインシステムにAI対応が進む中、事例調査から見えたのは、「AI体験をどうデザインするか」と「AIにどうデザインさせるか」の二本柱だという指摘。

前者は透明性、期待値の明示、過信の防止、ユーザー主導、フィードバック収集といった原則でAIの見せ方・振る舞いを整える動き。後者はllms.txtやdesign.md（AI向けの要点集）、MCPやCLI（AIが部品に直接アクセス・操作する仕組み）、Agent Skills（手順書）を整備し、AIが規約に沿って実装できるようにする流れ。

この結果、デザイナーは「AIが迷わないレベルまでルールを言語化する役」、エンジニアは「CLIや接続口など基盤を整える役」へ比重が移り、最終判断と責任は人に残ると述べている。

OpenAIがChatGPTを大幅アップデート。無料ユーザーも最新の「GPT-5.6 Luna」を標準で使え、来週からは無制限のテキストチャットに加え、難問に使える「Think」ボタンで無料でも最新モデルと高度推論を解放。

有料のPlus/Pro向け「GPT-5.6 Sol」も強化。質問に合わせた適切な詳しさ、不要な体裁の回避、妥当な修正提案に加え、日付や数値など事実の誤りを減らす設計。応答のトーンをモード間で一貫させ、各回答の思考時間を選べるスライダーも追加。

Amazon DynamoDBにネイティブなベクトル検索が搭載され、運用データと同じDynamoDBで直接ベクトル検索できるようになった。1桁ミリ秒の応答と99%以上の再現率を保ち、サーバーレスで自動スケールし、別のベクトルDBや同期パイプラインが不要になる。

最大4096次元、コサイン・ユークリッド・ドット積の距離、インラインフィルター、パーティションキーによるスケールをサポート。RAGやレコメンド、異常検知などの意味検索アプリを、従量課金のまま大規模に構築できる。AWS全商用リージョン（GovCloud含む）で一般提供。

AI生成で実装速度は上がる一方、AIが書いたテストは読みにくく、仕様書はすぐ古くなるため、どこを壊してはいけないかが見えにくい問題がある。

解決策として、MVP期は軽いPLAN/JUDGEで素早く作り、以降は保証台帳（docs/guarantees.md）を中心に運用するGDDへ切り替える。Issueで保証を事前承認し、実装・テスト・台帳を同時更新して、保証台帳で約束を先に裁可してから実装する運用により、影響範囲と守るべき挙動を明確化し、二重管理コストはAIに負担させる。

効果は「次に開くべき1枚」が固定され手戻りが減る点。一方で台帳と実装のズレはCIで完全には拾えず信頼に依存するため、定期監査やテスト名突合せで補いつつ、対象は外部から観測できる挙動に限定する。