AI新聞

Claudeと公式ドキュメントをもとに、AWSでWebリクエストを受ける8つの構成と守り方を整理した記事。

• まずは VPCオリジン / OAC が第一候補。使えない時だけ、プレフィックスリスト＋秘密ヘッダーでフォールバック。
• プレフィックスリストだけでは不十分。他人のCloudFrontも同じIP帯から来るため、秘密ヘッダー照合が本体。
• CT Logでオリジン用のホスト名は必ず露出する前提。「隠す」より「そもそも届かない」構成にする。
• CloudFront＋VPCオリジン＋CloudFront-VPCOrigins-Service-SGで内部ALBを閉じる。WAFは中身検査、VPCオリジン/SGは経路制御と役割を分ける。
• 公開ALBを使う場合は、秘密ヘッダーでfail-closed、HTTPS必須、ヘッダーは定期ローテーション。
• S3とLambda関数URLはOAC必須。署名はalwaysにして、S3はバケット公開OFFとSourceArn制限。
• API GatewayはRegional＋自社CloudFrontが推奨。直接叩きを避けるためx-api-keyをオリジンヘッダーで付与。
• Private APIはVPCエンドポイント経由でALBに背負わせて閉域を維持。
• Global Acceleratorは固定IPやTCP/UDP向けだが、防御はSG/WAF設計が要。HTTPだけならCloudFrontが有利。
• CloudFront側の基本チェック: HTTPS必須、ログ有効化、WAF関連付け、オリジン暗号化、OAC/VPCオリジン利用、推奨TLSポリシー。

AIエージェントで毎朝の本番セキュリティ確認を自動化した実践記事。

• 既存のダッシュボード/アラームの抜けを棚卸しし、AIに4系統の読み取りを任せた（入口/WAF、ログイン失敗、クラウド改変兆候、アラーム履歴）。
• 許可リストの読み取り専用＋スケジュール実行。書き込みは社内ノート1件のみ。
• タイムゾーンをJSTで統一、ログスキャン量の上限管理を明記。
• 固定閾値はやめ、直近7日の中央値と比較。1件で危険なものだけ固定赤。
• 社員の通常作業で誤検知が多発したため、実行者/回線/MFA有無で緑・黄を再定義。
• 色は「人が動く必要があるか」で決める。防げている/原因が明確なら黄色にしない。
• API名だけ数える監視は誤報の元。設定値まで条件に入れ、検証で意図どおり鳴るか確認。
• AIの「無い」は未発見の意味として扱い、コストを見てログ出力先や粒度を最適化。

生成AIがコードを書く前提になり、開発のやり方が大きく変わっている。著者はICからTechLead、VPoEを経験した立場から、単なる技術知識ではなく、AIがコードを書く時代にTechLeadは何で価値を示すのかを問い直す。

チームの成果を最大化する役割や、求められる振る舞いを具体的に考えることで、現役・志望者が自分の立ち位置と行動をアップデートするきっかけにしよう、という主張。

ISUCONでClaude Codeが完全自律で8時間走り優勝した出来事を扱いながら、著者はそのインパクトよりも、事前のハーネス（自動実験の枠組み）検証が本質と指摘する。過去問で回す評価ループの設計、動的コード生成でのデバッグ、スコアと残時間から走行を自動停止する判定ツールなど、徹底した準備が勝因だと見る。

また、人間向けインターフェースを外しAI同士で作業を回す発想や、評価がはっきりした課題では人がゴールだけ示す方が強いという示唆を述べる。最終的な解はPostgres排除や事前計算など古典的最適化も多く、AIの仮説検証と地道な理解を組み合わせる重要性を強調している。

Claude CodeとOrcaを使い、タスク管理を司令塔エージェントに任せる運用の実例。人がやるのは、司令塔が出す確認待ちに短く答えることだけ。

• 確認待ちを一箇所に集約し、番号で即答する運用。例：「41 OK」で返すと記録や連絡は司令塔が実行。
• /coordinatorでGitHubとNotionを同期。PR/IssueをNotion化し、人の判断が要るものだけ確認待ちに入れる。
• 着手順は「他人が自分を待つもの→期限が近い→他タスクの前提」の順で自動決定。
• 「人に見せる前」で止めるルール。PR提出前やレビュー投稿前で人の確認を挟む。
• 作業役の迷いには選択肢＋おすすめを提示。人は選ぶだけ。
• 自分しかできない作業（aws sso login など）も確認待ちに載せ、OK/Cancelで処理。
• レビューコメントはN1/N2…から選択して指示。
• コマンド許可待ちの作業役はパネル最上部で赤表示し、見落としを防ぐ。

有名OSS5件のエージェント用ハーネス（AGENTS.md、ルール、スキル、フック）の設計を比較し、設計の肝はAIへの信頼度でハーネスの縛り方が変わるという指摘。

• Zed：構造の説明は書かない。慣れていても踏む「罠」だけを短く明示（非自明・繰り返し・具体的の3条件）。
• Sentry：ルートのAGENTS.mdは索引だけ。詳細は領域別AGENTS.mdとスキルに分離（60行目安、100行未満）。
• OpenClaw：自走を許すが、止まる条件と「聞くべき判断」を取り決め（破壊的操作や有料利用は必ず確認）。
• Bun：文章で頼まず、フックで誤コマンドを実行前に停止し、その場で正しいコマンドを返す。
• PostHog：強制力の強い順に規約を実装（リンター→コミット時チェック→スキル→文章）。スキルは変更内容ごとに指定。
• 設計の始点は「AIの何を任せ、何を任せないか」の線引き。任せるならZed/Sentry型、手順統一はPostHog型、反復ミスはBun型が参考。

IPAの「AI時代の要求管理ハンドブック」は、AI活用前提の開発に向けて、目的起点で継続的に全工程をつなぐ要求管理の実践法をまとめた資料。何を実現したいかを出発点に、要求・要件を業務・データ・設計・評価・運用へ一気通貫で結び、変化に合わせて更新する進め方を解説する。

AI特有の不確実性やデータ品質、人とAIの役割分担を要件に落とし込む視点や、AIによる要求抽出・分析・文書化支援も網羅。モデリングとトレーサビリティ、法規・社内規則との接続、組織への定着ステップまでカバーし、経営・現場・開発から法務・調達まで幅広く使える。

ゲームデザイナーとしての立場から、いまの生成AIは使っていない。発想の壁打ちにも用いず、グラフィックでも信頼が足りず、他人の成果を食い物にする形になってはいけないと述べた。自分たちで考えたほうが、現状は良いものができるという。

一方で、いまの開発は重すぎ、数百万本売れても赤字の例があるため、完全に背を向けると遅れる不安もある。どこでどう使うかは未定で、いまは使わないが、搾取を避けつつ可能性は無視できないという姿勢で、ゆっくり付き合っていくとしている。

Anthropicの社内進捗を調べた公開METR報告を受け、AIの自動化によりAI能力の進歩速度が過去比で約2倍に達し、同社の加速基準を実質的に超えたと述べる。主因は人手ではなくAIによるR&D自動化で、研究者の実効生産性は4〜9倍、今は約10倍規模に達している可能性が高い。

この加速は頭打ちの明確な要因が見えず、加速が自己増幅して短期で超知能に至り得ると警鐘を鳴らす。単純計算では1年以内の極端な能力到達も視野に入る。

一方で産業界の備えは不十分で、機密モデルの防御、全量ログ監視、合意形成と減速ガバナンス、堅牢な整合性手法が欠ける。報告の多くが非公開で、危機感の共有と対策の合意が遅れかねないと訴える。

GoogleのAI開発プラットフォーム「Antigravity 2.29」は、クラウドで動くリモートエージェントで、長時間タスクを途切れず継続できるのが目玉。ブラウザを閉じても動き続け、GitHubリポジトリやGoogleドライブをリモート環境に自動マウントして作業できる。

Gemini Liveを使う音声モードも追加され、会話ページやAutomations、内蔵ブラウザの使い勝手が大幅に改善。Jupyterノートブック表示やショートカット編集にも対応し、利用には個人向けのGoogle AI Pro/Ultraプランが必要。

話題の論文は、AstraがQwenの重みを丸ごと理解したのではなく、コードで内部活性を調べて仮説→重み編集→検証を回せることを示したという内容。著者は「人間に不可能な新能力の発見」ではなく、汎用LLMが重みの解析・編集を自律的に実行できる点が本質だと指摘する。

検証としてAstraに任せ、語尾を「のだ／なのだ」に変える編集を実施。100問中77問、新規50問中36問で成功し、変更は重みの約0.486%のみ。プロンプトや微調整でやると思われがちな口調変更が、重み介入で再現でき、しかもAIに工程を丸投げできたことに驚きがあると述べている。

Claude CodeのようなAI時代に、読まれる文章へ最短距離で導く実践テクをまとめた記事。

• 読者と目的を明確化し、読者じゃない人・ゴールじゃないことも先に決める
• 目次から作り、構成に合意してから本文へ（AIにもまず目次を書かせる）
• 結論先頭＋詳細は隠す（補足は折りたたみ・別ページ・リンク）
• 箇条書きはグループ化し、親見出しで全体像を掴ませる
• 途中で見せて方向確認。冒頭だけ自筆→AIに文体を継がせる
• インラインコメントで注釈・議論を本文外に逃がす
• 図で流れを可視化。Mermaidに飽きたら表現を少し“ずらす”
• 参照元や前提、日付・版を明記し、後からたどれるようにする
• 書かない/消すを選ぶ勇気。冗長なら短文に割る
• 読み直しで関心を分離（説明文と自分メモを分ける）
• 読者を一人に絞る、用途別に分割、FAQや読み方案内を置く
• ツールで文脈管理を活用。まずは「自分が読みたい文」を書く

エージェントが書いた大量のコードを、人が行ごとに読まずに信頼するための研究プロトタイプ。PDD Kitは、仕様を平易な言葉でレビューし、コードが仕様どおりかはVerus（Rust向けの証明ツール）が機械的に確認する。つまり、行レビューをやめて意図レビュー＋機械による形式証明に置き換える。

証明できない部分は「信頼する境界」として切り出し、契約を明記しテストで裏づける。PRには「何を証明し、何を信頼し、何は保証しないか」がレシートのように出る。現時点ではRust限定のプロトタイプだが、ログインや権限など高リスク部分から強い保証を与えられるのが特徴。