AI新聞

Claude CodeのOpus 5で「思考が浅い・散文になる」症状への対処をまとめた記事。

• 原因はモデルの性能ではなく、Opus 5のsystem prompt（モデルに最初から渡される前提指示）が大幅に簡素化され、書き方規定が消え「十分なら即行動・網羅より推奨」を強めたため。旧rulesはこの前提に合っていなかった。
• 新system promptと自分のrulesを突き合わせ、衝突箇所は本体の原文を引用し「こちらを優先」と明示して上書きする。
• 「〜するな」はやめ、望ましい動きを具体的に書く。発火条件は「ユーザーが訂正した」など観測できる事実で書く。
• 指示を届ける層を選ぶ。output styleは書式には効くが進め方では負けやすい。UserPromptSubmit hookで毎発話の直後に1行注入すると強力。行動の直前に短く毎回届ける指示が最も効く。
• モデル更新＝system prompt更新と考え、挙動が急変したらrules追加前に本体の変化を読む。

AIエージェントが高速に実装できる一方、人間の理解が追いつかないと検証力や変更のしやすさが落ち、理解不足は複利で膨む負債になると指摘する。恐れが増してコードに触れにくくなり、品質もAI任せになりがちだという。

筆者はリリース条件として「説明できないものは出さない」を掲げ、目的・実現方法の骨子・影響と検証を自分の言葉で語れる状態を重視する。出典付きの説明や動くサンプルでAIに理解を補助させ、チームで握る抽象度も合わせることで、目先の速度より将来のコストを下げるべきだと述べる。

米議会に「AIが暴走したら政府が強制停止できる」AIキルスイッチ法案が提出され、NVIDIAやMicrosoft、Metaなど25社が反対の共同書簡を公開した。彼らは、少数企業が独占するより、モデルの重みを公開して多くの目で検証するほうが欠陥を早く直せるとして、オープンにすることが安全を強めると主張する。

一方で、公開後は回収不能というリスクも認める。中国発の強力なオープンモデル台頭への警戒が法案の背景にあり、OpenAIやAnthropic、Googleは署名していない。

筆者はフリーソフト文化の経験から、公開が技術を鍛えるという見方に同意する。最終的に法案の是非は議会審議に委ねられる。

Claude Opus 5の公式プロンプトガイドを読み解き、旧モデルの常識が逆効果になる点をまとめた記事。

• デフォルトで応答が長くなるため、「短く簡潔に」などの簡潔さ指示を常設する
• effortは思考量の設定で、応答の長さは変わらない。短くしたいならプロンプトで制御
• 「検証して」「再確認して」等の検証指示は削除。Opus 5は自動で検証するため、重複でコスト増
• 思考はオンのまま。effortはhighから始め、品質を見つつlow/mediumも活用。xhigh/maxは重タスク向け
• サブエージェントは使いすぎる傾向。大きく独立した作業に限定し、検証用途には使わない
• 狭いタスクはスコープを明示して脱線を防ぐ。レビューはまず網羅、重要度の絞り込みは後段で行う
• 旧プロンプト資産（Opus 4.8/Fable 5向け）は、委任や検証方針が逆な点を中心に見直す

総務省の白書をもとに4カ国の生成AI利用を比べ、日本は利用経験58.8%で、米独の75.6%、中国の93.6%に届かない。毎日使う人の割合も日本は29.9%と低い。

日本はテキスト生成が中心（55.0%）。音声や音楽、コード生成は一桁台にとどまる。未利用の理由は「必要ない」「使い方がわからない」が多く、後者の比率は各国で最も高い。

AIの受け止めは日本で「機械・道具」「辞書」、米国は「友人」、ドイツは「カウンセラー」。つまり日本は仕事中心、米独は相談相手として使う傾向が強い。企業利用は日本86.4%で、各国と大差はない。

米政府が「学習済みの重み（オープンウェイト）」の公開を規制する動きに対し、MicrosoftやNVIDIAらが連名で反対の書簡を公表した。公開は研究の再現性や監査、セキュリティ検証、人材育成を促し、国内の競争力につながると主張する。モデルの重み公開を一律に縛る規制は米国のAIリーダーシップを削ぐという立場だ。

一方で、公開された重みが外国勢の追い上げや悪用（サイバー攻撃や有害物質設計の支援など）を招く懸念も示され、議論は割れている。多くの企業が賛同したがAnthropicは署名せず、Google経営陣も慎重姿勢を見せるなど、産業界内でも対応が分かれている。

Hermes AgentとSlackをつないで設計し、Linear起点で実装〜Draft PRまで回す手順を解説した記事。

• grill-with-docs → to-spec → to-ticketsで、Slack上の対話から設計書とチケットを自動生成
• Linear MCPを最小権限で連携し、チーム・ステータス・ラベルをAGENTS.mdで明示
• Planner（設計）とCoding Worker（実装）をプロファイル分離し、許可ツールも最小化
• CronジョブでTodoを監視し、依存関係を満たす1件だけを取得して実装・検証・Draft PR作成を自動化（gh利用）
• VPSでGateway常駐させ、スマホからも指示可能。Linearのチケットから自律的に実装してDraft PRまで到達する運用例が核

AI生成の文章やスライドは説明が過剰になりがちで、読む側に理解の負担を強い、結局「何が言いたいか」が残りにくい。発信の目的は相手の行動を変えることであり、丁寧さはわかりやすさではないと述べる。

だからこそ情報を削って磨き、「ひとこと」に凝縮せよと主張する。AIに任せて詰め込む前に、自分はAIを使いたいのか、それとも受け手に動いてほしいのかを立ち返って考えるべきだ。