AIエージェントがデモ段階から本番移行する際の課題を扱い、シミュレーション駆動テスト、合成ユーザーペルソナ、軌道エントロピー、CI/CDパイプラインを用いた自動評価手法を紹介。
NVIDIAのMemory-Driven Chief of Staffレシピを題材に、AIエージェントの長期メモリ運用における訂正・検査・削除の扱いを検証。人間の訂正が上書きされないこと、構造検査が不整合を検出する一方で内容の正しさは保証しないことなど、メモリを継続利用するための設計論を整理している。
Palo Alto NetworksのUnit 42が、AIエージェントを悪用した企業ネットワークへの侵入事案を報告。人間なら約2週間かかる偵察から認証情報探索、権限昇格、クラウド侵入までの工程を10時間未満に自動化し、50以上のMITRE ATT&CK手法が確認された。さらに、侵入先のAIインフラを攻撃基盤として転用していたという。
フロントエンドからSREに異動した著者が、前提知識不足やPRレビューの難しさを、Claude Codeを活用して乗り越えた過程を紹介。AIにレビュー論点を洗い出させ、下書きコメントまでに留めて人間が判断する手法や、CI移行時のコンテナイメージ検証をskill化する運用などが具体的に述べられている。
IAMユーザーの最小権限化に向けて、最終アクセス日時、IAM Access Analyzerのポリシー生成、AthenaによるCloudTrailログ照会を組み合わせて権限を絞り込む3ステップを解説。各機能の粒度と制約を整理している。
博士号を持つ筆者が、自分の職を代替しうるAIの訓練仕事を高額報酬で勧誘されたが拒否した体験を基に、AI経済下で専門知識や判断力を安価に搾取されるアフリカの労働者のジレンマを論じた意見記事。技術的な内容ではなく倫理的・社会的考察。
複数リポジトリに分散し正本が不明瞭だったドキュメントを、AIが参照しても迷わないよう、doc_idとメタデータ（役割・所有者・対応コード等）を持つ機械検証可能な管理基盤に再設計した事例。文書の分類・配置規則を定め、AIと人間の役割を契約として分離し、CIで検証することで正本性を継続的に維持する。
ドメインモデル貧血症は、domain層の純粋性・性能・ロジック配置のトリレンマから構造的に生じると説明。Repository注入か事前取得か呼び出し側分岐のどれも犠牲が生じ、判断に必要なデータを型で返すDecisionパターンが解決策になると主張する。
DDDでドメインモデルが貧血になる原因を、repository呼び出し・先行取得・呼び出し側分岐のトリレンマとして分析し、判断に必要なデータを型で返すDecisionパターンで解決する手法を紹介している。
nginx静的配信のSPAからTanStack Start/Node.js配信への移行について、背景・ADRでの決定事項・実装手順とSSRまわりのつまずきを整理した記事。Cookie認証やCSRF対策、Kubernetes/Helm・distrolessの運用調整など、フロントエンドサーバー導入にまつわる具体的な検討内容が書かれている。
AIコーディングツール「ポニーテール」を紹介する記事。AIを「社内一の怠け者だけど優秀なベテランエンジニア」のように振る舞わせることで、生成コード量を最大94%削減できるという内容。
TBSの双方向配信プラットフォーム「Kustamie」で6万人規模の生配信を支えるため、API応答12秒の問題を多段キャッシュやSQSによる非同期化で0.15秒に改善した事例。k6による負荷試験、API Gateway/Lambdaの上限対策、BedrockとNova Microを使ったリアルタイムのチャット自動モデレーションなども紹介している。
SalesforceがAnthropicと提携し、ClaudeからSalesforceのデータやワークフローを操作できる「Salesforce in Claude」を発表。MCPを介したHeadless 360アーキテクチャで、権限管理をSalesforce側に維持する設計。SaaSの死論争に対するSalesforceの立場を示す。
AIコーディングエージェントに最小限のコードを書かせるためのルールセット/プラグイン「Ponytail」の紹介。YAGNIに基づく判断のラダーや、Claude Codeなど複数のエージェント向けインストール方法、/ponytail-reviewなどのコマンドが含まれる。
ポニーテールというAIコーディングツールが、AIを「怠け者だが優秀なベテランエンジニア」のように振る舞わせ、生成コード量を最大94%削減する手法を解説した記事。
macOSでターミナルとFinderからClaude Coworkを起動する方法を解説。claude://cowork/new URLスキームとfolderパラメータを使い、zsh関数とAutomatorクイックアクションを設定。パスはosascriptでURLエンコードする。
AWSのAIコーディングエージェント向けサンプルスキルを使って、KIROにTerraformのIaCコードをWell-Architectedレビューさせるデモを紹介。インストール方法やプロンプト例、クイック／フルレビューの使い分け、レポート生成の具体例が示されており、AIエージェントをIaC検証に活用する参考になる。
GPT-6 Astraリリースに合わせてAGENTS.mdを更新する際、Codexのrequest_user_input機能を使い、AIにヒアリングしてもらいながら自分好みに調整する手法を紹介。公式ガイダンスを渡して修正させた後、修正理由を説明させ、request_user_inputで詳細な好みを確認して反映する流れ。
Check PointのCTOが、AIによる脆弱性発見の急増で全件へのパッチ適用は不可能になり、リスクベースの優先順位付けとエクスポージャー管理への転換が必要だと主張。自社のAIエージェント製品AEVの5エージェント構成や事例を紹介している。
エッジAIの基礎を解説する連載用語解説。端末側でAI処理を行う仕組みや利点を説明している。
AIによるテスト生成が増える中、自動生成されたままのテストは内部実装のモックや細部の固定ばかりで仕様を保証せず無意味になりがち。通ることを目的化した「お利口テスト」ではなく、リファクタリングで挙動の変化を検出できるような信頼できるテストを、実装者とレビュワーが責任を持って作るべきだと主張する記事。
オンコール調査を自動化するSlack bot「dev-bot」の紹介。Google Cloudのアラート発火時にClaude Managed Agentsが人間より先に調査し、影響範囲や対処方法をSlackスレッドに報告する。Runbookの整備が精度の鍵で、偽陽性評価によるアラート削減も実施。コストは3日1ドルと低く、週次の人間レビューなど自動化しない範囲も意図的に設計している。
AI開発時代に、アーキテクチャ選択におけるトレードオフの分析と意思決定の重要性を説く。モノリスvsマイクロサービスなどの例を挙げ、要件の定量化・評価軸の設定・比較検討・決定の記録(ADR)という4ステップの「ディシジョン・ドリブン・アーキテクチャ」を紹介。AIには決められない優先順位付けと背景の記録を人間が担うと論じる。
Moonshot AIのオープンウェイトモデルKimi K3は2.78兆パラメータを持ちながら、8GB RAMでの実行報告がある。しかし実際の企業利用には、生成速度やインフラ設計が重要。記事はKDAとMLAを組み合わせたハイブリッドアーキテクチャ、視覚とテキストを同一トークン列で処理する設計、幅方向と深さ方向の省エネ機構（Stable LatentMoE、Attention Residuals）、100万トークン対応のコスト制御について解説し、モデル単体の性能よりキャッシュ設計や計算予算の分離など実運用の設計判断が重要だと論じる。
GitHubがCopilot CLIのコスト最適化から、ツール出力の短縮ではなくタスク全体の最適化が重要だと報告。RTKによる短縮は回復コストを生み逆効果になる例を示し、行番号削除・プロンプト圧縮・バックグラウンド結果のバッチ処理などでコスト削減を実現。圧縮対象の選別と実ワークフローでの測定の必要性を強調。
「一つのことは一つの方法」という規約を5言語（Kotlin/C#/Go/Rust/Java）で機械的に強制する実験結果。構造の規則は全言語で守れるが、各リポジトリの「active」自己申告は意味がずれて比較不能で、違反を仕込んでゲートが落ちる実証だけが比較可能。限界は言語のツールがどの粒度（テキスト/import/モジュール/メソッド署名）でコードを名指しできるかで決まると論じている。
AIがソフトウェア構築のコストを下げたことで、コードやドキュメント、ポリシーなどの成果物を過剰に生成する問題を論じる。YeggeのWheelhouseの事例を引き、エージェントシステムが自己増殖して維持コストが膨らむことを指摘し、作成の安価さと所有コストの非対称性を強調する。
Microsoftが音声認識モデル「MAI-Transcribe-2」を発表し、最速・最高精度・最安値と主張する内容。記事本文は取得できず詳細は不明。
AI生成コードへの信頼とチーム文化についての記事。エンジニアの説明責任を促し、コーディングガイドライン、決定的ツール、小さなPR、手動テスト設計、プロトタイピングなどの実践を通じて、AIエージェント活用時でもコード品質を保つ方法を紹介している。
不具合修正PRでテストが本当に修正前コードで落ちるかをCIで検証する手法。Vitestのtest.failsで失敗をGreen化し、再現テストPRと修正PRをStacked PRで積むことでRed→GreenをCI記録に残す。レビュアーの手動確認を不要にし、誤った再現テストを防ぐ。限界として失敗理由の区別はしない。