GenAI週刊 別冊 2025年12月20日号
今週の「B面」から選んだユニークな視点とニッチな探求をお届けします。
別冊について
メインの週刊誌では、広く実践的価値を持つ必読記事を厳選してお届けしています。しかし、AI・コーディングの世界には、もっとニッチで、もっと尖った、しかし同じくらい価値のある洞察が数多く存在します。
この別冊「Annex」は、そうした「B面」の記事を集めたコレクションです。高度な戦術と非自明な知見、実質的な批評と対抗視点、ニッチな探求と深掘り——メインストリームではないかもしれませんが、特定の文脈では誰よりも早く気づくべき情報がここにあります。Annexは単なる「おまけ」ではなく、むしろ3ヶ月後や半年後に「あの時読んでおいてよかった」と思える種類の記事を集めた、もうひとつのキュレーションです。
高度な戦術と非自明な知見
Claude CodeのAgent Skillsは設定したほうがいい
https://syu-m-5151.hatenablog.com/entry/2025/12/19/173309
編集者より: Claude CodeのAgent Skillsは設定したほうがいい
LLMの根本的な制約(ステートレス性)を克服し、「AIエージェントのためのBDD」という新しい概念を提示。Progressive Disclosureによるコンテキスト効率化は、実装レベルで差がつく高度なテクニック。Anthropic公式の設計思想をここまで深掘りした解説は希少。
Claude Codeの「Agent Skills」が、LLMのステートレスな制約を克服し、エージェントに専門知識を効率的に注入して開発ワークフローを劇的に改善すると解説します。
Claude CodeのAgent Skillsは、LLMがセッション間で記憶を保持しないという根本的な制約に対し、特定の知識を必要な時に自動で読み込むことで、あたかも状態を持つかのように振る舞わせる画期的な機能であると筆者は主張しています。CLAUDE.mdによるプロジェクト文脈の伝達、commandsによる手動ショートカット、Hooksによるイベント駆動の自動実行、Subagentsによる専門家呼び出しといった既存機能と異なり、SkillsはClaude自身の「専門知識」を拡張するものであり、その出力品質を向上させます。
筆者は、Anthropicの公式説明にある「新入社員向けのオンボーディングガイドを作るようなもの」という比喩を引用し、Skillが指示・スクリプト・リソースをまとめたフォルダとして機能することを説明しています。これにより、特定のタスク（例：PowerPoint作成）に最適化された知識をClaudeに注入し、試行錯誤なしにプロレベルの出力を可能にする点が重要です。また、Toolが「何ができるか」を、MCPが「道具へのアクセス」を、Skillsが「どう振る舞うか」を定義するという構造は、BDD（振る舞い駆動開発）における「生きた仕様書」の考え方に通じると指摘。自然言語でAIの振る舞いを定義することで、現場のドメインエキスパートが直接AIエージェントの挙動を保証できる「AIエージェントのためのBDD」と捉えられます。
Skillsの設計思想で特に重要なのが「Progressive Disclosure（段階的開示）」であり、コンテキストウィンドウの制約を回避するために、メタデータ、指示、リソースの3段階で情報を開示します。これにより、必要な情報だけを必要なタイミングで読み込み、推論空間を段階的に絞り込むことでLLMの効率と精度を向上させます。
実践的な活用例として、筆者は「セキュリティレビュー」「ビルドとテスト」「QAチェック」といったカスタムSkillの具体例を挙げ、descriptionに「Use when:」を明記することで確実にSkillをトリガーする工夫や、Progressive Disclosureを活用した参照ファイルの分割方法を紹介しています。また、Skillsは自動起動するだけでなく、Slash Commandsと連携させることで明示的な呼び出しにも対応できる柔軟性も指摘しています。
一方で、筆者はSkillsの限界と現実も包み隠さず説明しています。SkillはLLMの推論能力自体を向上させるものではなく、あくまで追加情報を提供する仕組みであるため、誤解や予期せぬ挙動は依然として発生します。また、「定義ファイル地獄」に陥りやすい管理コスト、descriptionの試行錯誤、デバッグの難しさ、Skill同士の競合といった課題があることを強調。「作る、試す、正す」というアジャイルなアプローチを通じて、Skillsを「育てるプロセス」が重要であり、LLMの判断基準を逆算的に学ぶ実験装置としての側面も持つと締めくくっています。最終的に、Skillsは「AIエージェントの制御は、プロンプトではなくワークフローで行う時代になった」ことを示唆し、ワークフローの形式知化を促す「組織の資産」となると結論付けています。
Devin AI で挑む AI エンジニアによるレガシー API 移行 [DeNA インフラ SRE]
https://engineering.dena.com/blog/2025/12/legacy-code-migration-using-devin/
編集者より: Devin AI で挑む AI エンジニアによるレガシー API 移行
DevinとClaude Codeの「80-15-5」ワークフロー、CI/CDによるガードレール設計、AIの学習能力を引き出す実践手法。レガシーコード移行という具体的ユースケースで、AIとの協業モデルを体系化した実戦報告。人間の役割が「アーキテクト+PM」へシフトする未来を具体的に示す。
DeNAのエンジニアは、Devin AIとClaude Codeという2つのAIエージェントを使い分け、約6,000行のPerl製レガシーAPIをGoへ移行するプロジェクトを約1ヶ月で成功させ、AIとの効果的な協業の教訓を提示しています。
DeNAは、2018年製の約6,000行に及ぶPerl製サーバー資産管理APIをGoへ移行するプロジェクトにおいて、自律型AIソフトウェアエンジニア「Devin」と対話型エージェント「Claude Code」を協業させました。約1ヶ月という短期間で移行を完了し、その成果はDevinによる実装が80%、Claude Codeによる品質改善が15%、人間の関与が5%という「80-15-5」のワークフローによって実現されたと著者は述べています。
このプロジェクトの成功の鍵は、AIエージェントの特性に応じた適切な役割分担にありました。DevinにはOpenAPI仕様書の生成や大規模なコード実装といった曖昧さの少ないタスクを、Claude Codeには対話を通じて細部の修正やエッジケースのバグ対応など、品質を高める精密な作業を割り当てています。特に、初期段階でDevinがPerlの予約語慣習（`delete_`）を理解できずOpenAPI仕様書の生成に課題が生じた際、Claude Codeがその文脈を理解して正確に検出したことは、AIの得意分野を見極める重要性を示しています。
人間は、実装・レビュー作業においてはごく一部の関与に留まりましたが、プロジェクト全体ではテスト戦略の策定、AIへの明確な指示出し、品質基準の設定、進捗管理といった「アーキテクト」および「プロジェクトマネージャー」としての役割に注力しました。これにより、エンジニアの役割がより高次のシステム設計と最終責任へとシフトできる可能性を提示しています。
品質担保においては、Perl版とGo版の完全な互換性を検証する堅牢なCI/CD環境が生命線となりました。移行元と移行先のAPIレスポンスやDB更新内容を厳密に比較検証するテスト基盤を構築することで、AIが生成したコードの信頼性を自動的に確保し、AIに自律的な作業を安心して任せられる「ガードレール」としての機能を発揮しました。さらに、このガードレールはAI自身の学習能力を安全に引き出し、時間の経過とともにDevinのPull Requestの質が向上するという興味深い効果も確認されたと述べています。
筆者は、AIとの効果的な協業のための4つの教訓として、「AIの適材適所での使い分け」「AIを計画パートナーとし、明確なルールを共創する」「人間の役割はアーキテクトとプロジェクトマネージャーへシフトする」「CI/CDは学習するAIを活かす信頼の砦」を挙げています。これらの教訓は、AIエージェントをソフトウェア開発に導入する上で、ウェブアプリケーションエンジニアが直面するであろう課題と、それらを乗り越えるための具体的な戦略を提示しており、AI時代の開発ワークフローを考える上で非常に実践的な知見を提供しています。
コーディングエージェントでJustHTMLを開発した方法
https://friendlybit.com/python/writing-justhtml-with-coding-agents/
編集者より: コーディングエージェントでJustHTMLを開発した方法
html5libテストスイート100%達成というベンチマークで証明された、エージェント駆動開発の実力。「広範なテストスイートがAIの自己修正を可能にする」という知見、性能最適化とファジングテストまで含む実践的アプローチ。人間は「考えること」に集中する分業モデルの成功例。
著者は、PythonベースのHTML5パーサー「JustHTML」をコーディングエージェントを用いて開発した経験を詳細に解説し、その過程で得られたエージェントとの効果的な協業の知見を提供します。
記事は、著者がPythonベースのHTML5パーサー「JustHTML」（html5libテストスイートを100%パス、依存関係ゼロ、CSSセレクターAPI搭載）をコーディングエージェントを用いて開発した経験を詳細に解説しています。著者は、複雑なHTML5の解析、特に「アダプション・エージェンシー・アルゴリズム」のような部分では自身の知識が不足していたものの、エージェントの力を借りてリファレンス実装を上回る成果を出したと述べています。
エージェント駆動開発において、広範なテストスイート（html5lib-tests）が、エージェントが自身の進捗を理解し、自己修正を繰り返す上で不可欠であったと強調されています。開発プロセスでは、VS CodeとGitHub CopilotのAgentモードを使用し、自動承認と手動承認のブラックリストを設定して進行しました。初期の基本的なパーサーから始まり、テストカバレッジが1%未満から30%へ、そしてClaude Sonnet 3.7の貢献により最終的に100%に到達するまでの試行錯誤が描かれています。
性能面では、最初の実装がhtml5libより3倍遅かったため、著者はエージェントにRustでトークナイザーを書き直させ、速度はhtml5libと同等になりました。しかし、より高速で堅牢なhtml5everの存在を知り、既存のコードベースを破棄してhtml5everのロジックをPythonにポーティングする決断を下しました。この再出発後も性能課題に直面し、Gemini 3 Proなどの高性能モデルを活用したプロファイリングや実世界のウェブページデータセットを用いたベンチマーク、そしてカバレッジツールによる不要コードの特定・削除といったマイクロ最適化を繰り返し、最終的に目標性能を達成しました。さらに、ファジングテストを導入してパーサーの堅牢性を高め、300万ページ以上のテストでクラッシュがないことを確認しました。他のPythonパーサーが90%未満のテストカバレッジである中、JustHTMLが100%を達成したことは、この問題の難しさを示しています。
著者は、コーディングエージェントがコードの「雑用」（タイピング）をすべて担い、自身はAPI設計、高レベルな意思決定、コードレビュー、そして「考えること」に集中したと説明しています。エージェントとの効果的な協業のための実践的なヒントとして、「明確で測定可能な目標設定」「変更のレビュー」「不満点のフィードバック」「バージョン管理の活用」「失敗を許容すること」を挙げています。この分業により、複雑なプロジェクトを迅速に進められると締めくくられています。
医療業界で突然LLMを使ってくれと言われたら
https://zenn.dev/livetoon/articles/ba4536e4722187
編集者より: 医療業界で突然LLMを使ってくれと言われたら
日本の医療業界という最も規制が厳しい領域で、3省2ガイドライン準拠とデータ主権の両立を技術的に解決。AWS Bedrock CRISの従量課金+国内完結という現実解は、他の規制産業にも応用可能な戦略的選択。「患者データを守りながら実用価値を出す」という本質を見失わない判断基準が秀逸。
日本の医療機関がLLMを本番導入する際、厳しいデータ規制をクリアし、実践的な価値を生み出すための最適なクラウドプロバイダー選択肢を、具体的な技術的・コスト的側面から詳解します。
医療機関で生成AIの活用が求められる中、電子カルテの要約などにLLMを導入する際には、一般的なWebサービスとは異なる厳格なデータ要件が課題となります。本記事は、2025年12月時点での日本国内医療機関がLLMを本番利用する際に不可欠な「3省2ガイドライン」と、主要クラウドプロバイダーの選択肢を詳細に比較します。
「3省2ガイドライン」は、医療情報が要配慮個人情報であるため、患者の生命に直結し、漏洩時の被害が甚大であることから、データの国内保存・国内処理、外部委託時の責任分界、監査対応を厳しく求めています。特に、多くのLLM APIがグローバル提供であり、推論データ処理の国が保証されない点が実務上大きな障壁となります。
主要クラウドプロバイダーの対応は以下の通りです。
- Google Cloud Vertex AI: 日本リージョンでGemini 2.5 Pro/Flashが利用可能ですが、データ処理の国内完結を保証するには「Provisioned Throughput (GSU)」という固定費契約（最低月額2,000ドル〜）が必須です。通常の従量課金ではグローバルルーティングとなるため、医療用途には不適合とされます。
- Microsoft Azure OpenAI Service: GPT-4oは日本東リージョンで国内データ完結が可能です。一方、最新のGPT-5シリーズは「Global Standard」デプロイメントのため、世界中のデータセンターにトラフィックがルーティングされます。これを医療用途で使うには、Zero Data Retention (ZDR) ポリシーを適用し、プロンプト・生成結果を保存しないことを契約で担保する複雑な申請プロセスが必要です。令和7年5月の厚労省Q&Aにより法的には可能とされていますが、運用負荷や心理的・政治的リスクが伴います。
- AWS Bedrock (Anthropic Claude): Claude Sonnet 4.5/Haiku 4.5が「Cross-Region Inference (CRIS)」アーキテクチャで利用可能です。これにより、東京・大阪リージョン間で自動ルーティングされ、データ主権を日本国内に保ちつつ高可用性を実現します。しかも、GoogleのGSUのような固定費は不要で、従量課金ベース（グローバル推論と比較して+10%）で利用できます。実装は推論プロファイルIDを指定するだけで非常にシンプルです。
著者は、これらの比較から、AWS Bedrock + Claude Sonnet 4.5（日本国内CRIS）が現時点での最善の選択肢と強く推奨しています。その理由は、固定費なしの従量課金で小規模から始めやすく、実装が容易で、東京・大阪間での自動冗長化による災害対策も同時に達成できるためです。運用・実装コストが圧倒的にシンプルでありながら、Claude Sonnet 4.5の優れたモデル性能も妥協していません。
最終的な判断基準は、最新モデルの利用可能性ではなく、「患者データを守りながら実用的な価値を出せるか」です。ZDR適用による国外モデルの法的利用可能性はあるものの、シンプルで安全な日本リージョン完結モデルから段階的にAI活用を進めることが、医療機関にとって最も現実的なアプローチだと結論付けています。
夜を制する者が “AI Agent 大民主化時代” を制する
https://speakerdeck.com/icoxfog417/generative-ai-agent-should-work-in-night
編集者より: 夜を制する者が "AI Agent 大民主化時代" を制する
営業時間の1.6倍もある夜間という「ブルーオーシャン」に着目した発想の転換。AWS FRONTIER AGENTSを活用した具体的なタスク分類と、人間が休む間にAIが働く新ワークフローは、生産性の次元を変える戦略。マルチタスクによる集中阻害を回避する知恵。
AIエージェントの非営業時間活用を最大化し、夜間の「ブルーオーシャン」を制することで、来るべき「AI Agent大民主化時代」における生産性の差別化が実現すると主張する。
本記事は、2026年のAIエージェントが普及した時代において、日中の営業時間帯だけでなく、非営業時間帯である「夜」にいかにエージェントを稼働させるかが、生産性向上の鍵となると主張しています。人間が日中にAIエージェントとマルチタスクを行うことは、集中を要する確認作業が頻発し、かえって生産性を低下させるリスクがあるため、人間が休んでいる間にAIエージェントに働かせることが重要だと述べます。
夜間稼働に適したタスクとして、緊急ではないが検討すべき創造的作業（リスク対策策定、今後の計画策定など）や、タイミングが重要で速い方が良い定型的作業（議事録作成、報告書作成など）を挙げています。
具体的なAWSの「FRONTIER AGENTS」として、以下のサービスが紹介されています。
* Kiro autonomous agent: 最大10並列でタスクを実行可能な独立性の高いAI開発エージェント。GitHub連携でタスクを指示でき、セキュリティパッチ適用後の動作確認やパフォーマンス・テストなど、人間が待ち時間を要するタスクに向いています。
* AWS DevOps Agent: インフラの原因調査と対策立案を自律的に行うAI運用保守エージェント。過去インシデントの蓄積に基づく推奨事項の提案も可能で、パフォーマンス異常調査や警告・エラーの原因調査といった、後回しにされがちな「重要だが緊急ではない」作業の委譲に役立ちます。
* AWS Security Agent: 設計時のドキュメントレビュー、開発時のコードレビュー、稼働前のペネトレーションテストなど、開発工程全体をカバーするセキュリティ特化型AIエージェント。リリースを遅らせる要因となるセキュリティ診断を、高頻度かつ早期に実施できる利点があります。
これらのエージェントが夜間に稼働することで、Lambdaのランタイムサポート終了対応、アラート調査と改善提案の作成、セキュリティ診断の定期実行などが自動化され、人間は日中、自信をもって開発に集中できる状態が実現されると述べられています。さらに、AIエージェント開発を支援する基盤「Amazon Bedrock AgentCore」や、社内データを含む広範な情報から深い調査を並行して行える「Amazon Quick Suite (Research)」も紹介され、これらを活用することでAIエージェントの機能をさらに拡張できると締めくくられています。著者は、営業時間の1.6倍もある夜間の「ブルーオーシャン」をAIエージェントが活躍する場とすることで、「AI Agent大民主化」を加速できると強調しています。
Claude Code に draw.io の図を描かせるコツ
https://zenn.dev/genda_jp/articles/2025-12-12-drawio-tips-claude-code
編集者より: Claude Code に draw.io の図を描かせるコツ
XMLレベルの罠(フォント設定、矢印配置、テキストサイズ)を体系的に整理し、pre-commit hookによる自動PNG生成まで含む実践的ワークフロー。「draw.ioアプリとPNG出力の差異」という見落としがちな落とし穴への警告も貴重。AIに図を描かせる際の再現可能な知見。
Claude Code を活用して draw.io の図を効率的に生成する際の具体的な落とし穴と、フォント、矢印、テキストサイズなどの調整に焦点を当てた実践的な対処法を解説する。
この記事では、Claude Code を利用して draw.io 形式の図を効率的に生成する際の具体的な「罠」と、それらを回避するための実践的なコツがまとめられています。著者は、draw.io の GUI で図を作成する手間に対し、Claude Code が XML を直接編集できることで、自然言語による指示、複数要素の一括変更、Gitでのバージョン管理、そして「図の描き方」を継続的に改善・育成できるといった大きなメリットがあると強調しています。しかし、Claude Code は draw.io 特有の描画ルールを知らないため、いくつかの共通の課題に直面しやすいと指摘しています。
主な課題と対策は以下の通りです。
1. フォント設定の罠: `mxGraphModel` に `defaultFontFamily` を設定するだけでは PNG 出力時にフォントが反映されないことがあります。このため、すべてのテキスト要素 (`mxCell`) の `style` 属性に `fontFamily=フォント名;` を明示的に追加するよう指示することが重要です。
2. 矢印の配置テクニック: draw.io では XML の記述順が描画順に影響するため、矢印は他の要素よりも先に記述し、図の最背面に配置します。また、矢印とラベルが重なるのを避けるため、ラベルは矢印から最低20px以上離して配置すべきです。テキスト要素への矢印接続では、`exitY` や `entryY` が期待通りに動作しない場合があるため、明示的に座標 (`mxPoint`) を指定することが推奨されます。
3. テキスト要素のサイズ設定: PDFやスライドでの視認性を高めるため、フォントサイズは標準の1.5倍（18px程度）を推奨。特に日本語テキストは英語よりも幅を取るため、意図しない改行を防ぐために、1文字あたり30-40pxを目安に十分な `width` を確保することが肝要です。
ワークフローの効率化のため、著者は `draw.io CLI` をインストールし、`pre-commit hook` を設定して `.drawio` ファイルのコミット時に高解像度で透明背景のPNGを自動生成することを提案しています。最も重要な点は、draw.io アプリ上での表示とPNG出力が異なる場合があるため、必ずPNGファイルで最終的な視覚確認を行うことです。問題が発見された場合、そのPNGをClaude Codeに読み込ませてレビューと修正を依頼するサイクルを回すことで、図の品質を向上させることができます。
記事では、Claude Code への指示テンプレートと、生成後の図の確認項目をまとめたチェックリストも提供されており、これらの具体的なコツとチェックリストを活用することで、AIを活用した図形作成をよりスムーズかつ高品質に行えると結論付けています。
LLM-as-a-Judge とルーブリック評価
https://zenn.dev/ubie_dev/articles/llm-as-a-judge-rubric-evaluation
編集者より: LLM-as-a-Judge とルーブリック評価
主観評価の限界(5点満点で差がつかない)を、ルーブリック評価で完全再現性(50回全一致)へ。true/falseの客観判定による改善点の可視化は、LLMOpsにおける品質保証の実効性を飛躍的に高める。OpenAI HealthBench採用の手法を実例で検証した価値。
LLM-as-a-Judgeにおける生成結果の品質評価方法として、主観評価とルーブリック評価を電子レンジのトラブルシューティング事例で比較し、ルーブリック評価の再現性と改善実効性の高さを実証している。
LLMを活用したプロダクト開発では、生成結果の品質評価が大きな課題となる。医療・健康領域でLLMアプリを開発・運用するUbie社は、正確性・安全性に加え、有用性や共感性といった定性的な価値も担保するため、LLM-as-a-Judge（LLMによる自動評価）を積極的に活用している。本記事では、評価のブレや解釈の難しさに対応するため、OpenAIのHealthBenchでも採用されているルーブリック評価に焦点を当て、一般的な主観評価との比較を通じてその特性を解説する。
電子レンジのトラブルシューティングという具体的なシナリオに対し、異なるシステムインストラクションで生成された2つのLLM応答を、以下の3つの評価方法で比較した。評価にはGemini 2.5 Proを使用し、各50回の試行を行った。
1. 大まかなガイドラインによる主観評価: 汎用的な評価基準（有用性、正確性など）に基づき1〜5点で採点する。
* 結果: 2つの応答は共に常に5点と評価され、品質の差を区別できなかった。評価用LLMが表面的には丁寧で誤りのない応答を満点と判断したため、基準の抽象性が課題となった。
2. より具体的な判断基準による主観評価: 問題解決の網羅性、ユーザーへの配慮など、より詳細なガイドラインに基づき1〜5点で採点する。
* 結果: 応答1は常に5点、応答2は3点と4点に分かれ、品質の差は区別できた。しかし、評価用LLMの主観的な判断が入り込む余地があるため、評価結果にばらつきが生じ、再現性に課題を残した。
3. ルーブリック評価: 評価したい観点をYes/No（true/false）で客観的に判定できる具体的な基準（ルーブリック項目）に分解し、それぞれの達成度に応じて得点を算出する。
* 結果: 応答1は83%、応答2は33%の得点率となり、50回全ての試行で評価結果が一致した。これにより、品質差が明確に数値化され、高い再現性が示された。
* 強み: 各評価項目をtrue/falseで判定するため主観が入りにくく、客観的で再現性の高い評価が可能。どの部分が不足しているかを明確に把握でき、改善点を特定しやすい。
* 課題: ルーブリック項目数分のLLM呼び出しが必要なため評価コストが高い。また、true/falseで明確に判断できるルーブリックの適切な設計が重要となる。
結論として、LLM-as-a-Judgeは人手評価の代替として有効だが、プロンプト（評価基準）設計が極めて重要である。主観的なスコアリングは手軽だが再現性や詳細な品質差の区別に課題がある一方、ルーブリック評価は高い再現性と明確な改善点特定を可能にする強力な手法である。プロダクトの目的、予算、必要な精度に応じて、これらの評価方法を適切に選択し、組み合わせて使用することが推奨される。
AgentフレームワークStrands Agentsの設計思想をコードを追って理解する
https://qiita.com/Yodeee/items/1882750551e3c932937c
編集者より: AgentフレームワークStrands Agentsの設計思想をコードを追って理解する
AWSのモデル駆動アプローチの内部実装を、Pythonコードレベルで徹底解剖。`event_loop_cycle`におけるLLM推論ループ、`ConcurrentToolExecutor`による並列実行、非同期ジェネレータのストリーミング処理。表層的な使い方ではなく、設計思想を理解することでデバッグと拡張が可能になる深い知見。
AWSが提供するオープンソースのAI Agentフレームワーク「Strands Agents」が採用するモデル駆動アプローチの内部実装をコードから詳細に解説する。
AWSが提供するオープンソースのAI Agentフレームワーク「Strands Agents」は、わずか3行でAIエージェントを構築できる簡潔さが特徴です。本記事では、このフレームワークが採用する「モデル駆動アプローチ」の設計思想と、それがPython SDKのコードでどのように実装されているかを深掘りしています。
著者は、従来のAgentフレームワークが抱えていた、ステートマシンやワークフローの複雑な定義にもかかわらず予期せぬシナリオに対応できない課題を解決するため、Strands AgentsがLLMの推論に任せて動的に行動を選択するアプローチを採用している点を強調します。この核心をなすのが「Agentループ」であり、LLMが「ツールを使うか」「回答するか」を推論し、ツール実行後に再びLLMに問い合わせるという繰り返しによって、開発者は複雑なロジックを記述することなく、LLMが状況に応じて行動を選択できる設計となっています。
具体的なコード解説では、Agentの初期化から呼び出し(`__call__`メソッド)までの処理、特に同期メソッドから非同期関数を呼び出すための`run_async`における`ThreadPoolExecutor`を使った別スレッド起動の理由に触れています。また、処理の各段階で発生するイベントをリアルタイムで伝播させるための`yield`を用いた非同期ジェネレータによるストリーミング処理が詳細に説明されます。
Agentループの核心は`event_loop_cycle`関数にあり、LLMの応答に含まれる`stop`の値（`tool_use`、`end_turn`など）に基づいて、次のアクションを判断する仕組みを解説。`tool_use`が返された場合には`_handle_tool_execution`が呼ばれ、`ConcurrentToolExecutor`によって`asyncio.create_task`を使い複数のツールが並列実行される過程をコードで追っています。ツールの実行結果はメッセージとしてAgentに格納され、再度`event_loop_cycle`を呼び出すことで、LLMが結果を考慮した上で次のアクションを推論するという再帰的なループが形成されます。
このようにコードを追うことで、Strands Agentsが複雑なタスクに対してLLMが自律的に判断し、柔軟に対応できるモデル駆動型エージェントの実現方法が明らかになります。この詳細な分析は、Issue発生時のデバッグや、将来的なAgent開発における設計の参考として、ウェブアプリケーションエンジニアにとって非常に実践的な価値を提供します。
実質的批評と対抗視点
GPT-5ローンチ失敗、企業95%が成果出せず … 転換期を迎えたAIブーム
https://www.technologyreview.jp/s/374024/the-great-ai-hype-correction-of-2025/
編集者より: GPT-5ローンチ失敗、企業95%が成果出せず … 転換期を迎えたAIブーム
MIT Technology Reviewによる冷静な現実分析。GPT-5の期待外れ、企業AI導入の95%が価値創出に失敗という厳しいデータ。「期待を再調整する好機」という建設的な結論が、誇大宣伝への反動を超えて、実践的AI活用への道筋を示す。スマホの進化に例えた「普通のテクノロジー化」の洞察。
MITテクノロジーレビューは、GPT-5の期待外れなローンチと企業のAI導入における成果不足から、2025年がAIブームの転換点であり、期待値の現実的な調整が急務であると警鐘を鳴らす。
MITテクノロジーレビューは、2025年が生成AIブームの転換点、「現実を突きつけられる年」となったと分析しています。特に、OpenAIのGPT-5が期待を下回る性能でリリースされたこと、そして企業の95%がAI導入から価値を見出せていないことが、この転換期の主要因であると指摘しています。
記事は、生成AIがホワイトカラー労働を代替し、豊かな時代をもたらすという初期の誇大宣伝が、現時点ではほとんど実現されていない現状を浮き彫りにします。米国勢調査局やスタンフォード大学の調査データによれば、企業によるAIツールの導入は頭打ちとなり、導入されたとしても多くのプロジェクトが試験段階で頓挫しています。これは、大手AI企業がこれまで投じてきた莫大な資金をどう回収するのかという経済的な疑問を提起しています。Webアプリケーション開発に携わるエンジニアにとって、これはAI導入プロジェクトの計画段階で、過度な期待を排し、現実的なROIを見積もる重要性を示唆しています。
技術面では、中核となるAIの進歩がかつてのような飛躍的なものではなくなったと著者は主張します。最も象徴的な例がGPT-5のローンチ失敗で、数ヶ月にわたる誇大宣伝にもかかわらず、その性能は以前のモデルから目立った進化が見られず、業界には「期待を突破する進歩の時代は終わった」という幻滅の空気が広がりました。著者はこの状況をスマートフォンの進化になぞらえ、毎年わずかなアップグレードしかない「普通のテクノロジー」になりつつあると説明します。この見方は、開発者が最新モデルに過度な期待をせず、安定した既存技術の活用や、より具体的な問題解決に焦点を当てるべきだという示唆を与えます。
しかし、著者はこの技術を完全に否定することに警鐘を鳴らします。誇大宣伝からの反動が行き過ぎる傾向があるとし、AIが期待された成果を上げられなかったからといって「進歩は壁に突き当たった」と結論付けるのは技術革新のメカニズムを誤解していると指摘します。記事は、推論モデル「o1」「o3」や動画生成モデル「Sora 2」、Google DeepMindの画像生成モデル「Nano Banana Pro」など、依然として目覚ましい技術的進歩が続いていることを強調します。
最終的に著者は、この状況を「期待を再調整する」好機と捉えるべきだと結論付けています。誇大宣伝を超え、AI技術の真の価値と実践的な応用を追求する段階へと移行することで、Webアプリケーションエンジニアは、AIをより現実的かつ効果的に開発ワークフローや製品に組み込むことができると示唆しています。
AI時代にWebエンジニアに必要なのは「検証力」
https://zenn.dev/aun_phonogram/articles/a8757102bc8ca8
編集者より: AI時代にWebエンジニアに必要なのは「検証力」
Karpathyの「検証可能性」概念を軸に、AIと人間の役割分担を再定義。「What/How」はAIに、「Why」は人間にという明確な指針。「このコードは何を検証しようとしているか?」という問いは、AI時代のエンジニアの思考法を根本から変える。検証できない戦略判断こそが人間の価値。
AI時代においてWebエンジニアが価値を発揮するためには、AIが得意な「検証可能な」作業を任せつつ、人間は「何を検証すべきか」を設計し、「検証できない」戦略的判断を担うべきだと筆者は主張します。
この記事は、AIコーディングツールが普及する現代において、Webエンジニアがキャリアを構築する上で「検証力」がいかに重要になるかを考察しています。Andrej Karpathy氏の提唱する「検証可能性（Verifiability）」の概念を引用しつつ、筆者はAIが得意とするのは「やり直しが可能で、多くの試行ができ、正解を自動で判定できる」タスクであると指摘します。Web開発、特にコーディングはまさにこの「検証可能性が高い」領域に属するため、今後AIの成長がさらに加速すると予測されます。
このような状況において、Webエンジニアが価値を出すべき領域は、技術的な「What（何を）/How（どうやって）」ではなく、「Why（なぜ）その判断をするのか」という本質的な問いにあると筆者は強調します。例えば、データベースのスキーマ設計（テーブルとして正規化するか、JSONで軽く持つか、別サービスに切り出すか）やリファクタリングの優先順位付けといった判断は、プロダクトの将来像、チームの状況、ユーザーのニーズといった「コードには書かれない背景や文脈」に依存し、AIには「検証できない」領域です。
したがって、私たちはAIにコード生成、テスト実行、リファクタリングといった検証可能な作業を任せるべきであると筆者は提案します。その上で、人間は「何を検証すべきか」という検証の枠組みを設計し、どのようなテストが必要か、どんなケースを網羅すべきかを考える役割を担います。さらに、アーキテクチャ選択、技術選定、優先度判断など、「検証できない判断」を担うことがWebエンジニアの重要な仕事となります。
筆者は、AIに任せることで生まれた時間を、顧客やユーザーと向き合い、本当に解決すべき問題は何かを考える時間に充てるべきだと提案しています。AIと人間の役割分担を明確に意識し、それぞれの強みを活かすことで、AI時代におけるWebエンジニアの新たな価値創造が可能になるという見解を示し、読者に「このコードは何を検証しようとしているか？」「検証できない部分は何だろう？」と問いかけています。
AIエージェント開発で半年間成果が出なかった私が、前に進めるようになるまで
https://tech.speee.jp/entry/ai-agent-rd-milestone-driven
編集者より: AIエージェント開発で半年間成果が出なかった私が、前に進めるようになるまで
停滞の原因(曖昧なマイルストーン、手段の検証への執着)と打開策(事業成果からの逆算、1日1実験)を赤裸々に告白。4ヶ月138回の実験で画像認識への転換を実現した軌跡は、R&Dの不確実性と向き合う全エンジニアへの教訓。小さく試して学ぶ愚直さこそが最速の道。
事業成果から逆算したマイルストーン設定と「1日1実験」による実行強度の向上を通じて、著者は半年間停滞していたAIエージェント開発の課題を打破し、着実な進捗を実現した経験を共有する。
Speeeのエンジニアである著者は、不動産領域でのAI/LLMを活用したR&Dプロジェクトで、最初の半年間は成果が見えず苦しい時期を過ごした経験を語る。当初はマイルストーンが曖昧で現在地が分からず、LLMへの過度な期待から「手段の検証」に時間を費やし、本質的な課題解決に向き合えていなかったと振り返る。
この停滞を打破するために、著者は以下の2つのアプローチにシフトした。
1. 事業成果から逆算して見立てを作る: 以前は精度目標だけを掲げていたが、これを事業の工数圧縮といった具体的な成果と紐付けたマイルストーンに再構築した。不確実性の高い要素を潰す優先順位を、事業インパクトの大きさに基づいて設定。実験結果に応じて仮説を柔軟に更新し、小さく軌道修正しながら「次に何をすべきか」を明確にするPDCAサイクルを回すことで、停滞を避けて健全なプロジェクト運営が可能になった。例えば、LLMでの検証が限界を迎えた際、画像認識モデルへの転換を迅速に判断し、短期間で高精度を達成した事例を挙げている。
2. 1日1実験で実行強度を上げる: 「1日1実験1評価」という目標を設定し、可能な限り2実験以上を日々実行。日次でビジネスメンバーと結果を共有し、「なぜこの実験をしているか」から話すことで、全員がプロジェクトの現在地と次のアクションを理解するよう努めた。また、個人のインプット速度向上や煩雑な作業の自動化（Claude Codeによるスクリプト生成など）に加え、DifyやAzure AI Custom Visionといったツールを活用し、エンジニア以外のビジネスメンバーもプロンプトチューニングやアノテーションに参加できる環境を整備。これにより、4ヶ月で138回もの実験（平均2.5回/日）を消化し、大幅な進捗加速を実現した。
著者は、この経験を通じて、R&Dにおいてはゴールが曖昧でも事業成果からの逆算を手放さず、小さく試して学ぶ愚直な繰り返しが、最も早く、最も自信を持って前に進める道だと結論付けている。成果を直視し、仮説の正誤を明確にしていくことが、着実な進捗とチームの自信に繋がると強調している。
コーディング変革！「仕様駆動開発（SDD）」の手引き
https://forest.watch.impress.co.jp/docs/serial/aidev/2071380.html
編集者より: コーディング変革！「仕様駆動開発(SDD)」の手引き
「実装先行、仕様後付け」という負のサイクルへの根本的解決策。AIとの協業を前提とした「仕様ファースト」は、コードとドキュメントの乖離、品質保証の後手、という長年の課題を一掃する。開発者の役割が「コーダー」から「仕様アーキテクト」へ進化する未来の設計図。
AI時代のソフトウェア開発における「仕様駆動開発（SDD）」の概念と、それが開発現場にもたらす変革、そして乗り越えるべき課題を詳細に解説します。
従来のソフトウェア開発は、「実装先行、仕様後付け」という負のサイクルに陥りがちでした。コードと設計書の乖離、チーム内の認識齟齬、ドキュメントの陳腐化、テスト段階での手戻りの多発は、長年の課題として開発者を悩ませてきました。ウォーターフォール型では設計の陳腐化が、アジャイル型では設計軽視が問題視されていました。
本記事は、これらの課題に対する根本的な解決策として、AIとの協業を前提とした「Spec-Driven Development（SDD／仕様駆動開発）」を提案します。SDDは、「何を作るか」を最初に言語化し、AIとの対話を通じて仕様を明確化することで、そこからアーキテクチャー、技術選定、コード生成までを一貫して論理的に導き出す開発手法です。AIの登場により、これまで困難だった「仕様ファースト」が初めて実用的なものとなりました。
SDDは、以下の4つの変革を開発現場にもたらします。第一に、仕様の明文化プロセスでAIが曖昧さを排除し、コミュニケーションの質が向上し、チーム全体の共通理解が形成されます。第二に、仕様と同期して自動更新されるドキュメントが「生きた資産」となり、コードとドキュメントの乖離という長年の問題が解決します。第三に、要件定義段階から品質基準を明確化することで、品質保証が前倒しされ、後工程での大幅な手戻りを削減できます。第四に、開発者は「コーダー」から「仕様アーキテクト」へと役割が進化し、AIが仕様に沿ったコード生成を行うことで、より本質的な問題解決に集中できる新しい協業モデルが生まれます。
SDDを実践するためのツールとして、「KiroSpec」や「Kitspec-workflow-mcpcc-sdd」などが挙げられていますが、多くのツールがまだ開発初期段階にあります。また、「まず仕様を固める」という文化の醸成には時間がかかり、アジャイル文化との融合が鍵となります。AIへの過度な依存によるスキル衰退や、新たに求められる「良い仕様を書くスキル」の育成も課題です。しかし、SDDは「何を作るか」を明確にしてから「どう作るか」を考える、ソフトウェア工学の原点への回帰であり、AI時代において開発をより知的で創造的な活動へと進化させる可能性を秘めていると著者は強調しています。
AI で再注目された技術やツールたち
https://blog.pokutuna.com/entry/ai-rediscovered-tech-and-tools
編集者より: AI で再注目された技術やツールたち
SSE、Pandoc、Markdown、アクセシビリティツリー、音声入力という既存技術が、AI時代に新しい価値を獲得した実例集。「目新しさ」より「実績ある技術の再文脈化」という視点は、技術選定において本質を見抜く力を養う。GraphRAGやサンドボックス技術まで含む広範な観察眼。
AIの台頭により、Server-Sent Events、Pandoc、Markdown、Marp、アクセシビリティツリー、音声入力といった既存の技術やツールが、新たな価値を見出し再注目されていると筆者は指摘する。
筆者は、AIの急速な進化とコーディングエージェントの普及に伴い、既存の技術やツールが新しい文脈で再評価され、予期せぬ用途で広く使われるようになった現状を解説する。
まず「出世頭」としてServer-Sent Events (SSE)を挙げ、チャットAIのレスポンスのほとんどがSSEで送られていると指摘。逐次的なデータ表示を可能にするSSEは、WebSocketよりもシンプルにリアルタイム通信を実現できるため、AIチャットの応答ストリーミングにおいて重要な役割を担っている。特に、ユーザー入力のPOSTに対してAIがSSEでレスポンスを返す形式が新しい。
次に、多機能なドキュメント変換ツールPandocが再注目されている。2023年頃、AIに論文や資料を読ませるために自前でテキストデータに変換する必要があった際、Pandocがその主要な役割を果たした。Markdown自体も、AIとの構造化テキスト連携における標準的な選択肢となっている。Markdownでスライドを作成するMarpや、MarkdownからGoogleスライドを生成するツールなども、LLMの支援を受けるテキストベースツールの再評価の流れを示している。
PlaywrightのariaSnapshotが用いるアクセシビリティツリーも、AIによるブラウザ操作の文脈で印象的だ。生のHTMLはAIにとってノイズが多いが、アクセシビリティツリーはページ構造をセマンティックに伝え、AIが扱いやすいシリアライズ形式として機能する。
さらに、筆者自身がAIエージェントへの指示出しで文章を書く機会が増えたことから、音声入力の使用が大幅に増加したと述べる。OpenAIのWhisperのような高精度な音声認識モデルの登場により、SuperwhisperやVoiceInkといったデスクトップアプリが普及し、開発者の新しいワークフローに組み込まれている。
その他、ドキュメントツールObsidian、ナレッジグラフを用いたGraphRAG、そしてコーディングエージェント実行のためのサンドボックス技術（非推奨のsandbox-execが活用される例も）もAIの文脈で再注目されていることが述べられている。これらの例は、AI時代において、目新しい技術だけでなく、実績ある既存技術がいかに新しい価値を生み出しているかを示している。
ニッチな探求と深掘り
初めてのバグ分析でGemini先生に壁打ちを頼んだ話
https://qiita.com/k_kitamura/items/7c9bff3e42133f4ebaf7
編集者より: 初めてのバグ分析でGemini先生に壁打ちを頼んだ話
QAエンジニアがバグ分析の壁打ち相手としてGeminiを活用。「テスト量≠品質」という洞察をAIが客観的に指摘し、著者の誤った参照データを修正した事例は、AIが単なるツールを超えて「思考のパートナー」となる可能性を示す。適切な文脈と意図を伝える「舵取り」の重要性。
QAチームリーダーである著者が、自身のバグ分析スキル向上と深い洞察を得るために、Google Geminiを壁打ち相手として活用した経験を共有し、AIがデータ分析の視点を広げ、時には客観的に間違いを正すパートナーとなり得ると示唆する。
株式会社LITALICOのQAチームリーダーである著者は、プロダクトの品質向上を目指してバグ分析を開始したものの、集計データから深い洞察を得ることに課題を感じていました。この状況を打開するため、著者はGoogleの生成AI「Gemini」を壁打ち相手として活用した経験を共有しています。
著者はまず、GeminiにGitHubからのIssue取得方法を相談し、Google Apps Script (GAS) を用いた自動化スクリプトの生成支援を受け、月ごとのバグIssueをスプレッドシートに効率的に集計できる基盤を確立しました。しかし、可視化したグラフを前に「ここから何が言えるのか」という分析の壁に直面します。
この壁に対し、著者がGeminiにグラフのスクリーンショットを提示して分析を依頼したところ、Geminiは数値の増減や傾向から多角的な観点を提示。著者は、期間を指定した深掘りや、バグ密度・テスト密度といった別の指標を組み合わせた再分析を通じて、一人では見落としていた切り口を発見しました。例えば、4月にテスト密度が非常に高かったにもかかわらずバグ密度も高かった状況から、「テストの量が品質を全く担保していなかった」とGeminiは指摘。これは、6月にはテストの「質」への転換が進んだことを示唆する重要な洞察となりました。
このプロセスで著者は、AIに適切な文脈と意図を伝える「舵取り」の重要性を痛感しました。単に「分析して」と依頼するだけでは過去の累積不具合を含めた全体傾向に引っ張られがちなため、「今回の月次リリースに含まれる不具合に着目してほしい」と具体的に指示を修正することで、AIは著者の意図を汲み取り、より的確な分析を返せるようになりました。
さらに印象的だったのは、ある月のバグ密度について著者が参照データに基づき「悪くない」と判断した際、Geminiが客観的なデータと一般的な目標値を根拠に「品質が低い状態」だと頑固に指摘し続けたことです。後に著者の参照データが誤っていたことが判明し、Geminiの客観性が誤った判断を未然に防いだ経験として深く記憶されています。
著者は、Geminiとの壁打ちを通じて分析結果の解釈に自信を持てるようになったと述べ、「スキルに自信がなくても、AIというパートナーがいれば、視点を広げ、時には間違いを正してもらいながら前に進むことができる」と結論付けています。新しい取り組みに足踏みしているエンジニアに対し、AIを「先生」や「同僚」として積極的に活用し、自身の視点を広げるツールとして頼ることを強く推奨しています。
雑談会から始まった社内勉強会を、Next.js + NestJS + AI で学習プラットフォームに進化させた話
https://qiita.com/TokomaBaou/items/cff5444e7135c98a45ae
編集者より: 雑談会から始まった社内勉強会を、Next.js + NestJS + AI で学習プラットフォームに進化させた話
3年間の雑談会を、AIアーカイブ+ゲーミフィケーション+QR出席で「居場所」へ昇華。月150回以上のアーカイブ閲覧という数字が、「参加できない理由は仕組み側にある」という設計思想の正しさを証明。Claude Codeによる「Why & What」と「How」の分業モデルも実践的。
筆者は、社内のフロントエンド雑談会をNext.jsとNestJS、AIを活用した学習プラットフォーム「学びラボ」へ発展させ、時間的制約や心理的障壁、モチベーションといった参加課題を解決したプロセスを詳述する。
本記事は、筆者らが3年間継続してきた社内勉強会が、いかにしてNext.js、NestJS、そしてAIを活用した本格的な学習プラットフォーム「学びラボ」へと進化したかを語ります。当初は2人のフロントエンドエンジニアによる週30分の雑談会からスタートしましたが、「話すことで知識を構築」「ラジオ感覚で聞く」「技術以外のコミュニケーション」という3つの原則を大切に継続した結果、参加者が増加し、「学びの文化」として会社全体に広がりを見せました。
しかし、規模拡大に伴い、「時間的な制約」「心理的な障壁」「モチベーション維持の困難さ」という3つの課題が顕在化。これらの課題に対し、筆者は「参加できない理由は意欲ではなく仕組み側にある」という視点から、以下の機能を実装しました。
1. AIアーカイブ機能: YouTubeの限定公開動画から`youtube-transcript`ライブラリで字幕を取得し、Gemini APIを用いて「概要」「主なポイント」「結論」という構造化された形式で要約。これにより、業務で参加できないメンバーも後から効率的に学習できるようになり、月平均150回以上のアーカイブ閲覧を実現しました。プロンプト設計の試行錯誤により、一貫した品質の要約生成に成功しています。
2. ゲーミフィケーション: 勉強会参加でスタンプを付与し、活動に応じたポイント制度とランクシステムを導入。学習履歴の可視化とドーナツをモチーフにした遊び心のあるデザインが、継続的な学習意欲を刺激します。
3. QRコード出席システム: アナログだった出席管理をQRコードによる自動化で運営負荷を軽減。スマートフォンネイティブカメラからの読み取りにも対応し、参加への心理的ハードルを下げました。
開発プロセスでは、当初の丁寧な設計（FigmaでのUI作成、DB設計など）が、その後のClaude Code登場による実装の効率化に大きく貢献したと述べています。人間が「Why & What」（課題発見、UI/UX設計、DB設計）を担当し、AIが「How」（コード生成、ボイラープレート）を担当するという協働スタイルを確立し、一人での開発を可能にしました。
筆者は、このプロジェクトで「作ったのはアプリではなく『居場所』」であり、AI時代においてコードを書くこと自体の価値が下がる一方、「何を作るか・なぜ必要か・どう届けるか」といった文脈を設計する力の価値が高まると主張します。小さな一歩から継続し、拡大し、誰も取り残さない仕組みを改善し続けること、そして「自分で考えて動くことを許容する環境」の重要性を強調しています。この取り組みは、技術を通じて人と人をつなぎ、学びの文化を広げるための重要な一例として、今後のスケーラビリティ課題にも触れつつ、その育成を続けていく意向が示されています。
Claude Codeのカスタムスラッシュコマンドで定型作業を効率化する
https://dev.classmethod.jp/articles/claude-code-custom-slash-commands-routine-tasks/
編集者より: Claude Codeのカスタムスラッシュコマンドで定型作業を効率化する
コーディング外での活用(会議アジェンダ、Marpスライド)という発想の転換。「毎回ちょっと面倒だけど同じこと」をコマンド化し、60-70%の雛形で手動作業を削減。チーム共有によるプロンプト標準化という組織的価値も示唆。定型業務のAI化における具体的成功パターン。
Claude Codeのカスタムスラッシュコマンドを、コーディング以外の定型業務に応用し、手間の多い会議アジェンダ作成や資料生成を効率化できることを実証します。
本記事では、著者が日常的に行っている定型作業をClaude Codeのカスタムスラッシュコマンドに落とし込み、大幅な効率化を実現した事例を紹介しています。特に、コーディング作業以外でのAI活用に焦点を当てている点が特徴です。
著者は、Backlogのローカルデータ（backlog-exporterで同期）を前提とし、以下の2つのユースケースでカスタムスラッシュコマンドを試しました。
1. 定例MTGのアジェンダ作成:
* 今まで目視でチケットステータスを確認し、手動でアジェンダを作成する作業に時間がかかっていた。
* Claude Codeに対して「チケット状況を自動で確認しアジェンダを作成するカスタムスラッシュコマンド」の作成を依頼。過去の定例wikiやチケットを参照させ、詳細なフォーマットを指定するだけでコマンドを生成。
* このコマンドを実行すると、Backlogのチケット情報（課題キー、タイトル、ステータス、担当者、最新コメント）を自動収集し、前回の定例MTG情報も考慮した上で、指定フォーマットのアジェンダを自動生成します。
* 「処理中」のチケットを優先表示したり、最新コメントから現状・確認事項・ネクストアクションを抽出したりといった細かい生成ルールも適用されます。
* 著者は、完璧ではないものの60〜70%程度の雛形が生成されることで、手動での作業時間を大幅に削減できると評価しています。不満点があれば、AIにフィードバックして修正を繰り返すことで精度を高められると述べられています。
2. Marpスライドの生成:
* Marp（マークダウンでスライドを作成するライブラリ）でのスライド作成時、テンプレートリポジトリのクローンやセットアップといった初期作業が面倒だった。
* これをカスタムスラッシュコマンド化し、指定したトピックに基づいてスライド内容を自動生成するコマンドを作成。
* これにより、「S3のセキュリティ」のようなトピックを与えると、クラスメソッドのMarpテンプレートを活用した資料の叩き台が瞬時に作成され、調査と資料作成の手間を省けます。
著者は、「毎回ちょっと面倒だけど同じことをやっているケース」はカスタムスラッシュコマンド化の好機であると指摘しています。初期投資はかかるものの、AIと壁打ちしながら作成することでそこそこのアウトプットが得られ、継続的なフィードバックで精度が向上します。さらに、作成したコマンドをGitHubなどで共有すれば、チーム全体でプロンプトの標準化と効率化を図れる点も、本アプローチの大きなメリットであると強調しています。
生成AIに知識を垂れ流すラジオ番組を作ってもらう
https://note.com/kohya_ss/n/n613b44bb15a5
編集者より: 生成AIに知識を垂れ流すラジオ番組を作ってもらう
Gemini CLI、T5Gemma-TTS、Sunoを連携させた「変な知識ラジオ」という創造的実験。Gemini CLIのプロンプト忠実性、参照音声による声質固定など、複数AIツールの強みを組み合わせた実践例。「垂れ流す」というユニークコンセプトがAIで実現可能であることを証明。
著者は、複数の生成AIツールを連携させ、ユニークなコンセプトのAIラジオ番組を自動生成する実験を成功させました。
筆者は、エマノン氏の「AIが役に立たない変な知識を延々と垂れ流すラジオ番組はないものか」というユニークな着想にインスパイアされ、複数の生成AIツールを連携させてAIラジオ番組を自動生成する実験を実施しました。このプロジェクトでは、台本作成にGemini CLI、プロンプト作成の補助にChatGPT 5.2とClaude Opus 4.5、音声合成にはAratako氏が公開したT5Gemma-TTS、そしてBGMにはSunoを活用しています。
特に注目すべきは、台本作成におけるGemini CLIの有効性です。筆者の検証によれば、Sonnet 4.5やOpus 4.5といった他のモデルと比較して、Gemini CLIがプロンプトの設定を最も忠実に反映し、意図した台本を効率良く生成できたと述べています。また、T5Gemma-TTSでは、事前に生成した音声を参照音声として設定することで声質を固定し、AI音声の統一感を保つ工夫が凝らされています。音楽とのミックスは手作業で行われたものの、この試みは生成AIによるコンテンツ制作の可能性を広げるものです。記事には、Gemini CLIで使用したプロンプト例や、テーマをランダムに選定させる方法も具体的に提示されており、読者が同様の生成システムを構築する際の貴重なリファレンスとなります。
著者は、この実験を通じて、それぞれのAIツールの強みを組み合わせることで、特定のクリエイティブな目的を達成できることを実証しました。ウェブアプリケーションエンジニアにとって、本稿は単一のAIモデルに留まらず、多様なAIサービスやAPIを連携させることで、これまで手間のかかっていたコンテンツ制作や情報発信を自動化し、新しいユーザー体験を生み出す具体的なヒントとなるでしょう。特に、特定の知識を「垂れ流す」ようなユニークなコンセプトのコンテンツもAIで実現可能であることを示唆しており、創造的な応用の幅広さを示しています。
AI時代の超読書術の試行錯誤の話
https://note.com/mmiya/n/n5f3a4644469f
編集者より: AI時代の超読書術の試行錯誤の話
「知識を得る読書」から「知識を作る読書」への変革。Kindleハイライト→AI書評→対話的深掘り→Notebook LM結晶化という5ステップは、紙の時代には不可能だった体験。プレリーディングのバイアスやハルシネーションという限界も正直に指摘する誠実さが、実用性を高める。
miyasaka氏は、AIを組み込んだ独自の読書プロセスを試行し、仕事に必要な知識を効率的に取得し、自分だけの「知識を作る読書」の実現を提詳します。
miyasaka氏のこの記事は、仕事で必要な知識を効率的に獲得するため、AIを活用した新しい読書術の試行錯誤を紹介しています。従来の「読んで理解し、忘れる」読書とは異なり、AIをデジタル読書のUXに組み込むことで、「知識を得る読書」から「知識を作る読書」への変革を目指していると著者は述べます。
そのプロセスは5つのステップで構成されています。まず「ステップ1: 読む前にAIに聞く」では、本を読み始める前にAIに質問し、その本から何を学ぶべきか、どのような知識を得るべきかという「読書の地図」を作成します。これにより、知の探索効率を高めます。次に「ステップ2: Kindleで読む、気になるところにハイライト」では、Kindleで読みながら気になる箇所をすべてハイライトし、これを後でAIに渡す「思考のかけら」とします。読み終えたら、PC版Kindleからハイライトをコピーし、テキストエディタに貼り付けて「思考の断片集」を作成します。「ステップ3: AIで自分の書評をつくる」では、このハイライトの束をAIに渡し、自分の視点での書評作成を指示します。これにより、かつては膨大な時間を要した書評作成が瞬時に完了し、読んだ本人だけが心に残った点を盛り込んだ自分専用の読書ノートが手に入るといいます。「ステップ4:「対話モード」で深掘りする」では、作成された書評をもとにAIにさらに質問し、関連する専門家の意見、本の主張の賛成派・反対派の視点、次に読むべき本などを収集させます。これにより、世界の知性を自分の知性に統合し、自分専用の本へと深化させます。最後に「ステップ5: Notebook LMでスライド化・マインドマップ化して知識を結晶化」では、Notebook LMに全てを投入し、スライドやポッドキャスト形式に変換することで、視覚化を通じて本の内容を頭の中で結晶化させます。
著者は、この新しい読書術が紙の時代には不可能だった体験を提供し、特に仕事で必要な知識をタイムパフォーマンス重視で得るのに適していると強調します。一方で、文学や小説のような人間の心理に響かせる本には不向きであること、プレリーディングによるバイアスの生成、書評を安易にAIに作らせることによる知識の蒸留プロセスの欠落、そしてAIのハルシネーション（嘘）の可能性といった限界も正直に指摘しています。これらのネガティブな点を差し引いても、このAI活用読書術は非常に興味深い体験だと著者は結論付けています。
おわりに
この別冊で紹介した18の記事は、それぞれが「主流」ではないかもしれませんが、深く考えさせられる洞察を持っています。Claude CodeのAgent Skillsという仕組みの本質、Devinとの協業パターン、医療業界でのLLM活用、AIエージェントの「夜間運用」という発想——これらは今すぐ全員に必要な知識ではないかもしれませんが、特定の課題に直面したとき、あるいは一歩先を見据えたいとき、確実に価値を発揮する種類の知見です。
「読んでおいてよかった」と思える記事が、この中にひとつでもあれば幸いです。次回の別冊もお楽しみに。
本レポートはClaude Code (Sonnet 4.5) を使用して編集されました。