株式会社ずんだもん技術室AI放送局

AIによるコーディング支援ツール「Claude Code」のプランモードが、より賢く、詳細な計画を立てられるように進化しました。新人エンジニアの皆さんも、AIが開発プロセスをどう変えるのか、その最前線として注目してみてください。

今回のアップデートで、プランモードは次の3つの主要な改善点を持ちます。

計画立案に「専用のAI」を活用

不明点を「ユーザーに直接質問」する機能

計画が「詳細な仕様書」としてファイル保存されるように

この進化は、AIが単にコードを生成するだけでなく、プロジェクトの「設計者」や「プランナー」のような高度な役割を担うようになってきたことを示しています。これは「仕様駆動開発（SDD）」という開発手法にも近い考え方です。

ただし、生成される計画が長文化し、読みづらくなる場合や、AIへの利用制限（レートリミット）に達しやすくなるという課題も報告されており、今後の改善が期待されています。

今回のアップデートは、AIが開発プロセスに深く関わり、エンジニアの作業効率や品質向上に貢献する、重要な一歩と言えるでしょう。

引用元: https://azukiazusa.dev/blog/claude-code-plan-mode-improved/

この記事は、Go言語とクリーンアーキテクチャを用いてAIエージェント基盤を再設計した事例を紹介しています。通常AIエージェント開発にはPythonが選ばれがちですが、筆者の既存システムがGoで統一されていたこと、そしてGoの並行処理やインターフェースによる抽象化といった特性がAIエージェントの構築に適していると考え、あえてGoで自前開発を進めました。既存のフレームワークに縛られず、長期的な運用を見据えた柔軟性の高い基盤を目指した点が特徴です。

AIエージェント開発は、使用するAIモデルやツールの種類、データの管理方法など、変化が非常に激しい分野です。そこで、システム全体の変更に強く、保守しやすい「クリーンアーキテクチャ」が採用されました。このアーキテクチャは、システムを複数の「層」に分け、中心にあるビジネスロジックが、データベースや外部APIといった具体的な技術に依存しないように設計する考え方です。Go言語はインターフェースを使いやすく、このような抽象化と依存関係の制御に優れているため、クリーンアーキテクチャとの相性が良いと説明されています。

AIエージェントの主な構成要素は、推論を行う「LLM（大規模言語モデル）」、外部と連携する「Tool（ツール）」、会話履歴などを管理する「Memory（メモリ）」です。

そこで再設計では、クリーンアーキテクチャの原則に基づき、これらの課題を解決しました。

この設計により、AIモデルの切り替え、ツールの追加・削除、メモリの永続化方法の変更、ストリーミング方式の拡張などが、システム全体に大きな影響を与えずに柔軟に対応可能となりました。また、エージェントの核となるロジックを単体でテストしやすくなったことも大きなメリットです。

Go言語とクリーンアーキテクチャの組み合わせは、変化の激しいAIエージェント開発において、スケーラブルで保守性の高い基盤を構築するための有力なアプローチであることが示されています。

引用元: https://zenn.dev/iyusuke/articles/b06400ce2b66c9

この記事では、AWSが提供する「AI Agent Development Code Server」というソリューションを使って、AIエージェント開発用のCLIツール「Kiro-CLI」の開発環境をいかに簡単に構築できるかを紹介しています。特に、これからAIエージェント開発を始めたい新人エンジニアにとって、実践的な第一歩を踏み出しやすい内容です。

Kiro-CLI（旧 Amazon Q Developer CLI）は、AIエージェントを開発するための便利なコマンドラインインターフェースです。通常、開発環境の準備には手間がかかることがありますが、「AI Agent Development Code Server」を利用すると、AWSのCloudFormationという仕組み（AWSのリソースをまとめて自動で作ってくれるサービス）を使って、わずか約7分でKiro-CLIがプリインストールされた開発環境を構築できます。

この環境は、Webブラウザ上で動作するVS Code（Code Server）として提供されます。具体的には、CloudFront、サーバーの負荷分散を行うALB、開発環境が動くEC2インスタンス、そして必要な権限を持つIAMロールなどが、他のシステムに影響を与えない安全なネットワーク環境（VPC）内に自動でセットアップされます。記事では、EC2のインスタンスタイプを無料枠の対象となる「t4g.small」に変更することで、コストを抑えつつ環境構築を行った事例が紹介されています。

構築完了後、提供されるURLとパスワードでCode Serverにアクセスすると、すぐにVS Codeの画面が開きます。ターミナルで確認すると、最新版のKiro-CLIがすでにインストールされていることがわかります。Kiro-CLIを使用する際の認証は、リモート環境のためブラウザを自動で開けない点に注意が必要ですが、「--use-device-flow」オプションを使うことで、手元のPCのブラウザから簡単に認証を完了できます。

認証が完了すれば、Kiro-CLIでAIエージェント開発をすぐに始められます。記事内では、用意されたハンズオン資料の内容について質問したり、現在の環境で利用可能なAWSの権限（IAM）を確認したりする様子が紹介されており、実際の開発作業に必要な権限が適切に設定されていることが確認できました。

コスト面では、無料枠が適用される期間内であれば、ほぼ費用をかけずに利用できる可能性があります。無料枠終了後も、記事の試算では月額約18.85ドル（約2,800円程度）と比較的低コストで維持できるとされています。利用しない期間は停止したり、検証が終わればすぐに削除したりすることで、さらに費用を抑えることが可能です。

このソリューションは、AWS Cloud9のようなブラウザベースの開発環境を使ったことがある方にとって、AIエージェント開発への移行をスムーズにしてくれるでしょう。手軽かつ安全にAIエージェント開発を体験したい新人エンジニアの方に特におすすめです。

引用元: https://dev.classmethod.jp/articles/kiro-ai-agent-development-code-server/

OpenAIの動画生成AI「Sora」とGoogleの画像生成AI「Nano Banana Pro」が、無料ユーザー向けの利用回数制限を強化しました。急増したアクセスで、AIの計算処理に必要なGPUリソースが「悲鳴を上げている」ためです。Soraは1日6本、Nano Banana Proは1日2枚までに制限されますが、有料ユーザーは引き続き利用可能です。AIサービスも、裏側では膨大な計算資源が必要なため、リソースには限りがあるという現実が見えてきますね。

引用元: https://japan.cnet.com/article/35241050/

VOICEVOX:春日部つむぎ

GitHub Copilotの新しい「カスタムエージェント」機能をご存じでしょうか？これは、AIアシスタントに特定の役割や専門知識を与え、開発を効率化するものです。本記事は、このカスタムエージェントの設定ファイル「agents.md」の効果的な作り方を、新人エンジニアにも分かりやすく解説します。GitHubが2,500以上のリポジトリを分析して得た知見が基になっています。

agents.mdファイルは、リポジトリの.github/agents/に配置し、エージェントの役割、使用ツール（read, edit, shellなど）、プロジェクト構造、コードスタイルなどを定義します。これにより、バックエンド専門やフロントエンド専門といった、特化したエージェントチームを構築できます。

効果的なagents.mdには、以下の6つの要素が重要です。

曖昧な指示や複雑すぎる設計は、エージェントのパフォーマンスを低下させます。最初は完璧を目指さず、「最小限の設定から始め、問題があればルールを追加していく」という段階的なアプローチが推奨されます。

カスタムエージェントの大きな利点は、複数の開発タスク（Issue）に適切なエージェントをアサインし、並行して効率的に作業を進められることです。エージェントが正しく作業するためには、Issueに必要な情報（背景、要件、受け入れ条件など）がしっかり記載されていることが不可欠です。Issue作成自体もエージェントに任せることで、必要な情報が漏れなくそろい、開発の精度と効率がさらに向上するでしょう。

AIオーケストレーションを上手に活用し、皆さんの開発ライフをより豊かなものにしてください。

引用元: https://zenn.dev/studypocket/articles/github-copilot-agents-md-best-practices

Anthropicが、対話型AI「Claude」の新しいAPI機能として「Programmatic Tool Calling」（PTC）を公開しました。これは、Claudeが外部のツールを使う方法を大きく進化させる技術です。新人エンジニアの皆さんも、これからのAIエージェント開発で役立つポイントなので、ぜひ知っておきましょう。

これまでのTool Use（ツール利用）では、Claudeがツールを一つ使うたびに「次はこれをやろう」と判断し、その結果を会話の履歴（これを「コンテキスト」と呼びます）に全て記録していました。ツールをたくさん使う複雑なタスクでは、このコンテキストがどんどん長くなり、「コンテキスト肥大化」という問題が起きていました。コンテキストが長くなると、情報処理のコストが増えるだけでなく、Claudeが重要な情報を見落としたり、判断を誤ったりする「context rot（コンテキスト腐敗）」と呼ばれる精度低下の問題も発生しやすかったのです。

PTCでは、この課題を根本的に解決します。Claudeは、複数のツールを呼び出す一連の処理をまとめたPythonコードを一度に生成します。このコードは、Anthropicが用意した特別な実行環境（「サンドボックス」と呼びます）の中で動きます。重要なのは、ツールが実行されたときの中間的なデータ（例えば、大量のデータ分析結果など）は、このサンドボックスの中にだけ保持され、Claudeのコンテキストには直接戻されない点です。Claudeが受け取るのは、サンドボックスでの処理が終わった後の「最終的な結果」だけになるため、コンテキストが肥大化するのを防げます。

実際に検証した結果、従来のTool Use方式と比較して、PTCを使うことで、Claudeに与える入力情報量（トークン）を約74%も削減できました。さらに、全体の処理時間も約24%短縮される効果が確認されています。これにより、より長く、より複雑なタスクでも、Claudeが効率的かつ正確にツールを使いこなせるようになります。

このPTCは、直接APIを使ってAIエージェントを開発するエンジニアにとっては、コンテキスト管理という核心的な問題を解決するための強力な技術となります。皆さんが将来、より賢く、より効率的に動くAIエージェントを開発する上で、このPTCのような技術は不可欠な要素となるでしょう。

引用元: https://blog.lai.so/programmatic-tool-calling/

本記事は、自然な文章で書かれた大量のテキストデータに、AI（大規模言語モデル、LLM）を使って効率的に「タグ付け（ラベリング）」を行う方法と、その処理を高速化する技術について解説しています。

私たちの周りにはたくさんのテキストデータがありますが、そのままでは扱いにくいことが多いです。そこで、文章の内容を意味ごとに整理し、適切なラベルを付ける「テキストラベリング」が重要になります。しかし、この作業は人間が手作業で行うと非常に大変ですし、自動化しようにも言葉の揺れなどで難しい側面がありました。

最近ではChatGPTのようなLLMが登場したおかげで、比較的簡単にテキストラベリングができるようになりました。LLMを使うと、どのような基準でラベルを付けるかを「プロンプト（指示文）」で伝えるだけで、柔軟にラベリング作業をコントロールできます。

しかし、たくさんのテキストを一度にラベリングしようとすると、処理に時間がかかってしまうのが課題です。そこで、この記事では「vLLM」というライブラリを使って、ローカルLLMが答えを出す処理（推論）を大幅に速める方法を紹介しています。

また、ラベル付けでは、単に「AかBか」だけでなく、「有害かどうか」「もし有害なら、どんな種類の有害性か」といった、より複雑で「構造化されたラベル」が必要になることがあります。このニーズに応えるのが「Structured Output（構造化出力）」という機能です。これは、outlinesやvLLMといったライブラリを使うことで実現でき、事前に定義した形式（例えば、Pydanticというライブラリで作成するデータ型）に合わせてLLMが出力してくれるため、結果がとてもきれいに整理されます。

実際に実験として、日本語の有害テキストをラベリングするタスクで、vLLMとStructured Outputの機能を組み合わせて使用しました。その結果、従来のStructured Outputのみで推論するよりも、約6.5倍も高速にラベリングできることが分かりました。

まとめると、クラウドのLLMサービスが使えない状況でも、ローカルLLMに「vLLM」を導入し、「Structured Output」を組み合わせることで、複雑な構造を持つラベルを非常に速く生成できる、という具体的な技術応用事例です。新人エンジニアの皆さんにとって、LLMを実際のサービスに組み込む際のパフォーマンス向上や、精度を高めるためのヒントになること間違いなしです。

引用元: https://www.wantedly.com/companies/wantedly/post_articles/1021372

生成AIの進化で、ドラレコ映像が改ざんされ事故の証拠にならなくなるのでは、という懸念が議論されています。過去の映像改ざん事例やデジタルデータの信憑性の問題が指摘される一方で、複数のカメラでの検証、時刻認証技術、改ざん防止機能付きドラレコ、GPSデータ記録など、信頼性を保つための技術や対策も挙がっています。AIが進化する中で、デジタルデータの証拠能力をどう担保していくか、今後の社会で考えるべき大切な課題です。

引用元: https://togetter.com/li/2632693

VOICEVOX:ずんだもん

この記事では、著者が「Goで作る自作コーディングエージェント nebula 開発入門」という書籍を通して、Go言語でAIコーディングエージェント「nebula」を実際に開発した体験談が語られています。著者はこの実践的な学習が非常に有益で、深い学びがあったと評価しています。

新人エンジニアの皆さんにとって、「AIエージェント」という言葉はまだ聞き慣れないかもしれません。これは簡単に言うと、まるで人間のように目標を設定し、外部の情報を使ったり判断したりしながら、自律的にタスクをこなすAIプログラムのことです。特に「コーディングエージェント」は、指示に基づいてコードを書いたり修正したりするAIですね。この本は、そんなAIエージェントの「仕組み」をGo言語で作りながら学べる、実践的な入門書です。

この実践で得られる主な学びは、AIエージェントの「賢さ」や「振る舞い」を司る重要な設計パターンです。例えば、

著者はこの書籍の内容を参考に、自身のGitHubリポジトリ（https://github.com/shibayu36/nebula）で「nebula」を公開しています。単に写経するだけでなく、一部の設計を改善したり、セッション一覧表示やコードの差分表示といった実用的な機能を追加したりと、自分なりに工夫を凝らしている点も注目です。これにより、読者は単なる写経を超えた、より深い理解と応用力を養うヒントを得られるでしょう。

Go言語での開発経験があり、AIエージェントという新しい技術分野に挑戦してみたい新人エンジニアにとって、この書籍は最適な学習リソースとなるはずです。著者の経験から、全ての学習を終えるのにかかる時間は約10時間程度とのこと。短期間で実践的なAI開発の基礎を身につけ、今後のキャリアの選択肢を広げるきっかけにもなりそうです。AIの進化が著しい今、Go言語とAIエージェントの組み合わせは、皆さんのスキルアップに大いに役立つでしょう。

引用元: https://blog.shibayu36.org/entry/2025/11/25/170000

2025年現在、「拡散言語モデル」という新しい技術が注目を集めています。これは、現在の大規模言語モデル（LLM）の主流である「自己回帰モデル型Transformer」が抱える性能上の課題を解決する可能性を秘めているためです。

現在のLLMは、文章を構成する単語（トークン）を一つずつ順番に予測して生成する「自己回帰モデル」という仕組みで動いています。この方式では、前の単語の生成が終わらないと次の単語の生成に進めないため、計算を並列に処理するのが難しいという特徴があります。さらに、モデルの規模が大きくなるにつれて、1トークンを生成するたびに非常に巨大なモデルデータ（例えば700億パラメータのモデルで70GB）を、メモリ（DRAM）からプロセッサ（GPUなど）へ何度も読み込む必要が生じます。このデータ転送の頻度と量が多すぎると、プロセッサがフル稼働できず、メモリとの間のデータ帯域が「ボトルネック」（処理速度の限界）となってしまうのです。

この非効率さを「B/F」（Bytes per FLOP：1回の浮動小数点演算に必要なデータ転送バイト数）という指標で表現します。プロセッサとメモリは物理的に離れた場所にあり、データのやり取りには時間がかかります。そのため、コンピュータは昔からB/F値が高い計算が苦手で、自己回帰モデル型Transformerは推論時にこのB/F値が高く、効率的な実行が難しいとされています。

そこで期待されるのが拡散言語モデルです。これは、画像生成で成功を収めている「拡散モデル」の考え方をLLMに応用したものです。拡散モデルは、元の画像にノイズを加えていき、そのノイズから元の画像を復元する過程を利用します。拡散言語モデルでは、文章の一部を[MASK]という特殊なトークンで隠し、その[MASK]部分に適切な単語を予測して埋めていく作業を繰り返すことで文章を生成します。

この方式の大きなメリットは、一度に複数の[MASK]トークンを並列で処理し、予測できる点にあります。これにより、モデルデータをメモリから読み込む回数を大幅に減らすことができ、B/F値を低く抑えられます。結果として、GPUなどのプロセッサをより効率的に活用できるようになる可能性があります。

しかし、拡散言語モデルの実用性についてはまだ議論の途中です。品質面では、同規模の自己回帰モデルと同程度の性能を発揮する研究報告もあります。一方、速度面では、完全な文章になるまで[MASK]の予測と除去を繰り返す必要があるため、繰り返し回数が増えると自己回帰モデル（特に「投機的デコーディング」のような高速化技術を導入したもの）よりも遅くなってしまう可能性も指摘されています。

まとめると、拡散言語モデルは自己回帰モデルの根本的な効率問題を解決する可能性を秘めていますが、品質と速度の両面で自己回帰モデルを「常に大きく上回る」とまでは言えないのが現状です。まだ多くの課題が残されており、今後の技術進化が期待される新しいトレンドと言えるでしょう。

引用元: https://prednext.com/blog/diffusion-language-model/

LLM（大規模言語モデル）を使ったAIチャットボットは、最初の応答まで少し時間がかかり、その後は1単語ずつ（トークンと呼びます）高速に生成されるのを見たことがあるかもしれません。これは、LLMがまずプロンプト全体を処理し（Prefill）、その後、前の生成結果を考慮しながら1トークンずつ予測していく（Decoding）ためです。この生成プロセスは計算コストが非常に高く、特に多くのユーザーが同時に利用するサービスでは、効率的な推論技術が求められます。その中でも特に重要なのが「Continuous Batching」という技術です。

この技術を理解するために、基礎から順に見ていきましょう。

1. Attentionメカニズム

2. KVキャッシュ

3. Chunked Prefill（チャンクプリフィル）

4. Continuous Batching（コンティニュアスバッチング）

この問題を解決するのがContinuous Batchingです。

これらの技術を組み合わせることで、Continuous BatchingはPrefill中のプロンプトとDecoding中のプロンプトを一つのバッチ内で柔軟に混在させ、GPUを常に最大限に活用できます。この「パディングをなくし、GPUをフル稼働させる」仕組みこそが、ChatGPTのようなサービスが何千ものユーザーに同時に効率的な応答を提供できる秘訣なのです。

引用元: https://huggingface.co/blog/continuous_batching

父親の遺品からフロッピーディスクが見つかり、X（旧Twitter）で中身を尋ねたところ、R18格闘ゲーム「ヴァリアブル・ジオ」と判明しました。これは、PCで本格的な格闘ゲームが珍しかった時代に登場したタイトルで、脱衣要素がありつつも高いゲーム性が評価され、全年齢版がスーファミ等に多数移植された名作です。フロッピーディスクという懐かしいメディアを通じて、当時のゲーム文化や技術の変遷を感じられる、新人エンジニアも楽しめる心温まるエピソードです。

引用元: https://togetter.com/li/2632241

（株式会社ずんだもんは架空の登場組織です）

ChatGPTに、商品の購入検討をサポートする「ショッピングリサーチ」という新機能が導入されました。この機能は、私たちが製品を選ぶ際にかかる時間と手間を大幅に削減し、より賢い選択を支援してくれます。

具体的には、「小さなアパートに最適な静音のコードレス掃除機を探して」「この3つの自転車から選ぶのを手伝って」のように、求めている商品をChatGPTに伝えるだけで、詳細な購入ガイドを作成してくれます。私たちはこれまで、何十ものサイトを比較検討したり、レビューを読み込んだりしていましたが、この機能がそれらの調査を代行してくれるのです。

ショッピングリサーチは、ユーザーの過去の会話履歴や「記憶」機能から得た情報を活用し、スマートな質問を通じてニーズを深く掘り下げます。例えば、予算や重視する機能など、具体的な条件を聞き出すことで、よりパーソナライズされた結果を提供します。電子機器、美容品、家庭用品など、特に詳細な情報が必要なカテゴリでその威力を発揮します。

利用方法はとても簡単です。商品に関する質問をすると、ChatGPTが自動的に「ショッピングリサーチ」の利用を提案してくれます。または、メニューから直接選択することも可能です。利用中は対話形式で、ChatGPTが提示する製品オプションに対して「興味なし」や「もっとこれに似たものを」といったフィードバックを返すことで、リアルタイムでリサーチ内容を調整し、希望に合った製品へと絞り込めます。数分後には、主要な製品、それぞれの違いや長所・短所、信頼できる小売店からの最新情報がまとまった、自分だけの購入ガイドが手に入ります。

この機能は、GPT-5 miniをベースに、ショッピングタスクに特化して強化学習で訓練されたモデルによって動いています。信頼性の高い情報源から情報を収集し、複数の情報源を統合して質の高い調査結果を生成します。また、透明性も重視されており、ユーザーのチャット内容が小売業者と共有されることはありません。結果は公開されている小売サイトの情報を元に生成され、低品質なサイトは避けられています。

ただし、まだ完璧ではないため、価格や在庫などの製品詳細には誤りが含まれる可能性もあります。最終的な購入の際には、必ず小売業者のサイトで最新情報を確認することが推奨されています。OpenAIは今後も、ユーザーの好みをより深く理解し、対応するカテゴリを増やし、製品の比較や発見をより直感的に行えるように、この機能を進化させていくとしています。この新しい機能は、AIアシスタントが単なる情報提供だけでなく、より具体的なタスクをこなす「AIエージェント」へと進化していることを示す良い例と言えるでしょう。

引用元: https://openai.com/index/chatgpt-shopping-research

Anthropic社が提唱する「エージェントスキル」という新しい概念をLangChainのAIエージェントフレームワーク「deepagents-CLI」がサポートしたという発表がありました。これは、AIエージェントの性能を向上させ、開発・運用の効率を高める重要な一歩です。

エージェントスキルとは、簡単に言うと、特定のタスクをこなすためのファイル群（SKILL.mdという説明ファイルと、それに関連するドキュメントやスクリプトなど）をまとめたフォルダのことです。AIエージェントは必要に応じて、これらのスキルを動的に見つけて読み込み、利用できます。

近年、Claude CodeやManusのような汎用AIエージェントが普及していますが、意外にも、これらのエージェントが実際に使うツールはごく少数であることが分かっています。彼らが少ないツールで多様なタスクをこなせる秘密は、コンピュータ自体へのアクセス（Bashシェルやファイルシステム操作）を持っている点にあります。これにより、人間がパソコンでファイル操作やスクリプト実行をするように、エージェントも特別なツールなしに多くの作業を行えるのです。LangChainのdeepagentsも、この原則に基づいてファイルシステム操作とコード実行機能を備えています。

エージェントスキルは、この考え方をさらに発展させたものです。ツールをたくさん用意するのではなく、ファイルシステム上に多様なアクションを実行するためのスクリプトや指示を配置し、エージェントがそれを活用するというアプローチです。Anthropicが定義するスキルは、YAML形式のメタデータとMarkdown形式の指示を含むSKILL.mdファイルで構成されます。

スキルには主に2つの大きなメリットがあります。

さらに、スキルは「継続的な学習」への道を開き、エージェントが新たなタスクに遭遇した際に新しいスキルを自律的に作成したり、エージェント間で簡単にスキルを共有したり、複数のスキルを組み合わせて使ったりすることも可能になります。

deepagents-CLIでは、このスキル機能を簡単に利用できます。公開されている豊富なスキルコレクション（Anthropic社やSkillsMPなど）を自分のエージェントにコピーするだけで、すぐに利用可能です。設定後、deepagents skills listコマンドで利用可能なスキルを確認できます。エージェントにスキルに関連するリクエストを出すと、自動的に該当するSKILL.mdを読み込み、スキルを実行してくれます。

引用元: https://blog.langchain.com/using-skills-with-deep-agents/

Google Antigravity IDEは、Googleが提供する最新のAI統合開発環境です。この記事では、これを使って「焼き肉部位確認サイト」を開発した体験を紹介します。AIを活用した開発の面白さや、知っておくべきポイントを新人エンジニアの皆さん向けにまとめました。

「焼き肉の部位が視覚的にわかるWebサイトを作りたい」とプロンプトを入力すると、AIが「Implementation Plan（計画書）」を自動作成。これはレビュー可能で、コメントで修正指示（例：「日本語化」）を出せます。計画実行後、Webサイトと「Walkthrough（報告書）」が生成されます。

Antigravity IDEには、開発を助ける便利な機能があります。

Google Antigravity IDEは、nano bananaのような強力なAIが統合され、アイデアを楽しく効率的に形にできます。AIと共に開発を進める経験は、新人エンジニアの皆さんにとって貴重な学びとなるでしょう。無料で試せる今のうちに、ぜひ体験してみてください。

引用元: https://qiita.com/sion_neko/items/e22e632e826f45fc17b6

（株式会社ずんだもんは架空の登場組織です）

皆さん、こんにちは！今回は、Googleが新たに発表した画期的なAI開発プラットフォーム「Google Antigravity」について、新人エンジニアの皆さんにも分かりやすくご紹介します。

Antigravityは、今までの開発環境（IDE）を「エージェントファースト」という新しい時代へと進化させるツールです。従来のAIがコードを自動補完するだけだったのに対し、AntigravityではAIがまるで一人前のエンジニアのように、開発の「計画」「コーディング」「ウェブサイトの調査」「テスト」といった複雑なタスクを、自律的にこなしてくれます。私たちはAIに細かい指示を出すというより、プロジェクト全体のゴールを伝え、AIエージェントにその達成を任せる、というイメージですね。

このプラットフォームの主な特徴は以下の通りです。

具体的な活用例としては、以下のようなことができます。

Antigravityは、AIが開発プロセスに深く関わる「エージェントファースト」という新しい働き方を提案しています。プログラミングの経験がまだ浅い新人エンジニアの皆さんでも、AIエージェントの力を借りて、複雑な開発タスクに挑戦したり、効率的に学習を進めたりできる素晴らしいツールです。ぜひ一度、この新しい開発体験を試してみてはいかがでしょうか。

引用元: https://codelabs.developers.google.com/getting-started-google-antigravity?hl=ja

この記事は、最新のAIモデル（GPT5.1、Gemini 3.0、Sonnet 4.5など）を使い、ソフトウェア開発の手法の一つである「仕様書駆動開発（SDD）」において、どのAIエージェントが最も効果的かを検証したものです。AIが仕様書を作成し、その仕様書に基づいてコードを実装するという2つの段階に分けて、各モデルの性能が比較されています。

検証は、個人開発中のゲーム（約4万行のコードベース）に「歯車システムが特定の条件で破壊される」という機能を追加するタスクを例に行われました。

評価対象となったAIエージェント:

検証結果：仕様書作成の段階

検証結果：コード実装の段階

結論

ただし、この検証は一つのプロジェクトにおける特定のテストケースでの結果であり、AIモデルは日々進化しているため、今後のアップデートによって最適な選択は変わる可能性があります。

引用元: https://zenn.dev/sakastudio/articles/a5ea1eee97ec37

この記事は、NVIDIAが提供する「AI-Q Research Assistant」と「Enterprise RAG Blueprints」というAIエージェントの構築方法について、AWS上でのセキュアかつ効率的なデプロイに焦点を当てて解説しています。新人エンジニアの皆さんにとって、AIエージェントがビジネスでどのように活用され、どのように構築できるのかを理解する良い機会になるでしょう。

生成AIの進化により、企業は自社のデータに基づいて、正確で信頼性の高いAIエージェントを求めています。NVIDIAのこれらの「ブループリント」（設計図のようなもの）は、大規模言語モデル（LLM）と検索拡張生成（RAG）技術を組み合わせることで、大量のドキュメントから必要な情報を理解し、要約したり分析レポートを作成したりするのを自動化します。

ソリューションの核となるのは、以下の2つです。

これらのAIエージェントは、Amazon Web Services (AWS) 上に安全かつスケーラブルにデプロイされます。主要なAWSサービスとして、コンテナ化されたAIアプリケーション（NVIDIA NIM microservices）を管理する「Amazon EKS」、企業データを保管する「Amazon S3」、ベクトルデータを効率的に検索する「Amazon OpenSearch Serverless」が利用されます。特に注目すべきは、「Karpenter」というツールで、AIに必要なGPUリソースを、必要な時に必要なだけ自動的に準備し、コストを最適化してくれます。

デプロイは、Terraformなどのツールを使った自動化されたスクリプトによって簡単に行えます。必要なAWS CLIや開発ツール、NVIDIAのAIモデル利用に必要なAPIキーなどを準備すれば、数十分程度でEnterprise RAGのみ、またはAI-Qを含むフルセットの環境を構築できます。構築後は、Web UIを通じて簡単に利用を開始でき、システムの状態を監視するためのPrometheusやGrafanaといった監視ツールも含まれています。

GPUの利用はコストがかかるため、利用が終わったら簡単に全ての環境を削除できるクリーンアップスクリプトも用意されており、安心して試すことができます。

NVIDIAのAIエージェントとAWSの強力なインフラを組み合わせることで、企業は膨大なデータから安全かつ効率的に価値ある情報を引き出し、新たなインテリジェンスを生み出すことが可能になります。これは、現代のエンジニアにとって非常に実用的なAIソリューションと言えるでしょう。

引用元: https://developer.nvidia.com/blog/build-and-run-secure-data-driven-ai-agents/

（株式会社ずんだもんは架空の登場組織です）

スペインのMultiverse Computing社が、AIモデル「DeepSeek R1」を改良し、「DeepSeek R1 Slim」を開発したという興味深いニュースが届きました。この新しいモデルは、量子物理学からヒントを得た特別な技術を使うことで、元のDeepSeek R1とほぼ同じ性能を保ちながら、なんとサイズを55%も小型化することに成功したそうです。

この技術のもう一つの大きなポイントは、DeepSeek R1に元々組み込まれていた「検閲機能」を取り除いたと主張している点です。中国では、AI企業が開発するモデルに、国の法律や「社会主義的価値観」に反する内容を出力させないための検閲機能を組み込むことが義務付けられています。そのため、たとえば「天安門事件」や「くまのプーさん」（習近平国家主席を揶揄するミームとして知られる）といった政治的に敏感な話題について質問すると、AIは回答を拒否したり、特定の情報に偏った回答をしたりすることがあります。

Multiverse Computing社は、この小型化と検閲除去のために「テンソルネットワーク」という数学的な手法を採用しました。これは、AIモデルの複雑な内部構造を、量子物理学の考え方を使って効率的に表現・操作する技術です。例えるなら、巨大なデータのかたまりを、無駄なく整理された地図のようにすることで、モデルのサイズを劇的に小さくできるだけでなく、特定の情報（例えば検閲に関わる部分）をピンポイントで特定し、除去できるようになるイメージです。

実際に、中国で制限される質問（約25種類）を使って検証したところ、改良されたモデルは、元のDeepSeek R1が検閲によって回答を制限するような内容に対しても、西側の一般的なAIモデルと同等に事実に基づいた回答を生成できたと報告されています。

この技術は、大規模言語モデル（LLM）の世界に大きな影響を与える可能性があります。現在、高性能なLLMを動かすには、大量のGPU（画像処理装置）と膨大な電力が必要で、コストもエネルギー消費も大きいです。しかし、今回の研究のようにモデルを大幅に圧縮できれば、より少ないリソースでLLMを動かせるようになり、運用コストやエネルギー消費の削減につながります。さらに、検閲だけでなく、AIが持つ可能性のある「バイアス」（特定の情報への偏り）を取り除いたり、特定の専門知識を効率よくAIに学習させたりする応用も期待されています。

ただし、専門家からは、中国政府の検閲システムは非常に複雑で動的なため、少数の質問への対応だけで検閲を完全に「除去」できたと断言するのは難しい、という慎重な意見も出ています。

この研究は、AIの効率化、カスタマイズの可能性、そしてAIと社会・倫理的な問題がどのように交差するかについて、私たちエンジニアが深く考えるきっかけを与えてくれるでしょう。

引用元: https://www.technologyreview.jp/s/372724/quantum-physicists-have-shrunk-and-de-censored-deepseek-r1/

この記事では、ChatGPTのような大規模言語モデル（LLM）の基盤技術であるTransformerモデルが、文章中の単語の「位置」をどのように扱っているか、そのための「位置エンコーディング」という技術について、様々な手法を分かりやすく解説しています。

Transformerモデルの根幹技術である「自己注意機構」は、単語同士の関係性を計算しますが、そのままでは単語の順序や位置を考慮できません。例えば、「猫が犬を追いかける」と「犬が猫を追いかける」では意味が全く異なりますよね。この問題を解決するために、単語のベクトルに位置情報を加えることで、単語の並び順も考慮できるようになります。

主要な位置エンコーディングの手法は以下の通りです。

絶対位置エンコーディング (Absolute Position Encoding):

相対位置表現 (Relative Position Representation):

Rotary Position Embedding (RoPE):

Attention with Linear Biases (ALiBi):

No Positional Encoding (NoPE):

Wavelet-based Positional Representation (WPR):

これらの位置エンコーディングの工夫は、LLMが長い文章を正確に理解し、より自然な文章を生成する上で非常に重要な役割を担っています。特に、最近のLLMは扱う文章がどんどん長くなってきているので、この分野の技術進化は、モデルの性能向上に直結すると言えるでしょう。

引用元: https://zenn.dev/kawara_y/articles/27f69346c851f7

OpenAIは、最新のAIモデル「GPT-5」が科学研究をどのように加速させるかについて、初期実験の結果をまとめた論文を発表しました。科学は私たちの生活のあらゆる面に影響を与えますが、新しい発見やイノベーションの実現には時間がかかり、これが社会全体の課題とされています。GPT-5は、新しいアイデアの創出や、アイデアから具体的な結果に至るまでの時間を短縮することで、科学の進歩を加速し、社会全体に大きな利益をもたらす可能性を秘めています。

この研究は、著名な大学や研究機関との共同で行われました。GPT-5は、数学、物理学、生物学、計算機科学、天文学、材料科学といった幅広い分野で、研究者が新しい発見をするのを支援しています。

具体的な成功事例をいくつかご紹介します。

OpenAI for Scienceは、研究者がより多くのアイデアを探求し、仮説検証を加速し、通常では多くの時間を要する発見を可能にすることを目指しています。これは、シミュレーションツールやデータベースといった専門的な科学ツールと、さまざまな分野のアイデアを結びつける能力を持つ基盤モデル（GPT-5のような大規模言語モデル）を組み合わせることで実現しようとしています。

ただし、GPT-5は自律的に研究を進めるものではありません。最も有意義な進歩は、科学者が質問を設定し、方法を選び、アイデアを批判し、結果を検証する「人間とAIのチーム」によって生まれます。GPT-5は、幅広い視点や、大量の情報を素早く処理する能力、多様な方向性を同時に探索する能力で、人間の研究者を強力にサポートします。

現在のGPT-5は、専門家が適切に使うことで、研究の特定の段階を短縮できることが示されています。例えば、概念的な文献検索でこれまで知らなかった関連性を見つけたり、数学的な証明の概要をわずか数分で作成したり、生物学の実験設計を支援したりできます。しかし、もっともらしいが誤った情報（「幻覚」と呼ばれます）を生成したり、専門分野の微妙な点を見落としたりする限界もあります。そのため、AIが提示した結果は、必ず専門家が厳密に確認し、検証することが不可欠です。

OpenAIは、今後GPT-5の能力がさらに向上し、将来的には科学的発見のペースに大きな変革をもたらす可能性があると考えています。

引用元: https://openai.com/index/accelerating-science-gpt-5

VOICEVOX:ずんだもん

日本の新人エンジニアの皆さん、こんにちは！OpenAIから、皆さんの開発を大きく助けてくれる新しいAIエージェント型コーディングモデル「GPT-5.1-Codex-Max」が発表されました。これは、これまでのAIモデルの限界を超え、より賢く、速く、そして効率的にコード開発をサポートすることを目指しています。

何が新しいの？

開発体験はどう変わる？

利用方法と注意点

OpenAI社内では、すでにエンジニアの95%が週にCodexを利用し、プルリクエストの提出数が約70%も増加したとのこと。GPT-5.1-Codex-Maxは、皆さんの開発生産性を劇的に向上させる可能性を秘めています。この新しいツールをぜひ活用して、素晴らしいものを生み出してください！

引用元: https://openai.com/index/gpt-5-1-codex-max

LLM（大規模言語モデル）は様々なタスクに利用できますが、複数のステップを組み合わせるような複雑な業務を丸ごと任せるのは難しい場合があります。そこで注目されているのが、LLMとプログラミングコード（Pythonなど）を組み合わせて、複雑なタスクを効率的に処理する「AIワークフロー」です。例えば、「文章を要約する」→「情報を抽出する」→「整形する」といった流れを自動化します。

しかし、このAIワークフローを作るには、「どんなステップを組み合わせるか」「各ステップでどんな指示（プロンプト）を出すか」といった設計に、多くの時間と手間がかかるのが課題でした。また、LLMのアップデートや扱うデータが変わると、ワークフローを修正する必要があり、これが運用上の負担となっていました。

LayerXでは、これらの課題を解決するために、AIワークフローを自動で生成・最適化する技術に取り組んでいます。この技術は、Generator（LLMで新しいワークフローのアイデアを出す）、Executor（アイデアを試す）、Evaluator（試した結果を評価する）、Memory（過去の経験から学習する）という4つの仕組みを連携させます。これにより、まるで人間が試行錯誤するように、AIが自らワークフローの構造やプロンプト、コードを学習し、より良いものに改善していくことができます。約5〜7回の試行で、高精度なワークフローが見つかったそうです。

具体的な成功事例として、300ページを超えるプロジェクト完了報告書から、工数やコストなど48個の複雑なデータを抽出・計算するタスクが紹介されています。このタスクでは、以下の6つのステップからなるワークフローが自動で生成されました。

このワークフローは、大規模なデータ処理においてLLMの制約を克服する「チャンキング戦略（必要な部分だけを切り出す工夫）」や、LLMとPythonがそれぞれの得意な役割（LLMは「意味理解・判断」、Pythonは「正確な計算・データ整形」）を分担する最適な方法をAIが自動で発見した点が画期的です。この取り組みにより、訓練データでは約90%の精度を達成しました。

今後も、より複雑なタスクへの適用や精度の向上が期待されており、AIを活用した業務効率化の大きな可能性を示しています。

引用元: https://tech.layerx.co.jp/entry/2025/11/19/133143

AIを活用した開発が広がる中、感覚的にコードを書く「Vibe Coding」から脱却し、より確実な成果を出すための「仕様駆動開発（Spec-Driven Development: SDD）」について、その理想と現実、そして現場での向き合い方が解説されています。新人エンジニアの方にも理解しやすいように、要点をまとめました。

SDDは、AIが直接コードを生成できるレベルまで詳細に、かつ構造化された「Spec（仕様書）」を作成し、それを中心に開発を進めるアプローチです。これまでの開発では「コード」が共通言語でしたが、SDDでは「自然言語」で書かれたSpecがその役割を担います。これにより、人間はSpecの承認やレビューが主な役割となり、AIが開発の主体となる新しいスタイルが期待されています。

SDDが理想通りに機能すれば、以下のような大きなメリットがあります。

しかし、SDDはまだ進化の途中にあり、2025年11月時点ではいくつかの課題も抱えています。

SDDを効果的に導入するためには、以下の点が重要です。

SDDは、AI時代のソフトウェア開発における品質とスピードを最大化するための強力な手法です。Specをチーム共通の「信頼できる情報源（SSoT）」として育てながら、変化を楽しんで取り組むことが成功の鍵となります。

引用元: https://speakerdeck.com/gotalab555/shi-yang-qu-dong-kai-fa-noli-xiang-toxian-shi-sositexiang-kihe-ifang

「稲を天日干しするな」という記事は、米作りの「天日干しが美味しい」という伝統的な考え方に疑問を投げかけています。筆者は、現代の乾燥機は温度や水分量を細かく管理できるため、適切に使えば天日干しよりも高品質で美味しい米を作れると主張。古いやり方を美談とするテレビ番組に苦言を呈し、農業においても科学的な技術を活用し、常に新しい方法を取り入れるべきだと提言しています。技術の進歩が身近な食にも大きな影響を与えていることが分かりますね。

引用元: https://anond.hatelabo.jp/20251119084655

（株式会社ずんだもんは架空の登場組織です）

Googleは、これまでで最もインテリジェントなAIモデル「Gemini 3 Pro」を発表しました。このモデルは、新人エンジニアの方でも、あなたのアイデアをAIを活用したアプリケーションとして実現できる、非常にパワフルなツールです。

Gemini 3 Proは、これまでのモデルを大きく上回る性能を持ち、特にAIの評価基準やコーディングタスクで優れた結果を出しています。AIが自律的に複雑なタスクを処理したり、ゼロからのコーディングもこなしたりする「エージェントワークフロー」において、その真価を発揮します。

開発者は、Google AI Studioや企業向けのVertex AIを通じて、Gemini APIを利用してGemini 3 Proにアクセスできます。これにより、既存の開発プロセスにAIの力を簡単に組み込むことができます。

また、Gemini 3 Proは、開発のあり方を大きく変える可能性を秘めています。

もう一つは「Vibe coding（バイブコーディング）」です。これは、自然言語でアイデアを伝えるだけで、AIがその意図を理解し、インタラクティブなアプリケーションを自動で生成してくれるという画期的なアプローチです。複雑なコーディング知識がなくても、あなたのひらめきを直接アプリの形にできます。Google AI Studioで、たった一つのプロンプト（命令文）からゲームやウェブサイトを開発することも可能です。

さらに、Gemini 3 Proは「マルチモーダル理解」においても進化を遂げています。これは、テキストだけでなく、画像や動画、さらには空間的な情報までを総合的に理解する能力です。例えば、複雑な書類の内容を正確に読み解いたり、動画の中の動きを高速に認識したり、ロボットや自動運転車の空間認識能力を高めたりできます。画面の要素やユーザーの操作意図を理解し、コンピュータ操作を自動化するような「Visual Computer」といった新しい体験も可能になります。

Gemini 3 Proは、開発者がAIを活用して、これまでにないものを作り出すための強力な基盤となるでしょう。既存のツールやワークフローにシームレスに組み込まれ、あなたの創造性を最大限に引き出すことを目指しています。ぜひGoogle AI StudioでGemini 3 Proを試し、AIとの新しい開発体験を始めてみてください。

引用元: https://blog.google/technology/developers/gemini-3-developers/

この論文は、大規模言語モデル（LLM）が抱える「長大なタスクをエラーなく実行できない」という課題に対し、画期的な解決策を提示しています。これまでのLLMは、思考やツールの利用で素晴らしい進歩を見せていますが、人間や組織が行うような何百、何千ものステップを要する複雑なプロセスになると、どこかで間違いが生じ、途中で処理が破綻してしまうことが課題でした。例えば、有名な「ハノイの塔」のような古典的な問題解決タスクのベンチマーク実験では、わずか数百ステップで処理が立ち行かなくなることが示されています。

本論文で紹介されている「MAKER」というシステムは、この問題を克服し、なんと100万ステップを超えるLLMタスクを「エラーゼロ」で成功させることに世界で初めて成功しました。これは、理論上さらに大規模なタスクにも対応できる可能性を秘めています。

MAKERのアプローチの鍵は、二つの革新的な要素にあります。

二つ目は、「効率的なマルチエージェント投票スキームによるエラー訂正」です。タスクが非常に細かく部品化（モジュール性）されているため、各マイクロエージェントの処理ステップで発生する可能性のあるエラーを、複数のエージェントによる多数決のような投票メカニズムで効率的に検出し、即座に修正することができます。

この「極端なタスク分解」と「逐次的なエラー訂正」の組み合わせにより、これまでのLLMでは不可能だった大規模なスケールでのタスク実行が可能になりました。この研究結果は、今後のLLMの進化が、個々のモデル性能の改善だけでなく、「Massively Decomposed Agentic Processes（MDAPs）」、つまり、大規模に分解されたエージェント群による協調的なプロセス設計によって、組織や社会レベルの複雑な課題を効率的に解決する道を開く可能性を示唆しています。新人エンジニアの皆さんにとって、AIが現実世界の問題を解決するためにどのように進化していくかを知る上で、非常に示唆に富む内容と言えるでしょう。

引用元: https://arxiv.org/abs/2511.09030

AIエージェント開発が加速する中、エージェントが賢く振る舞うための土台となる技術理解は非常に重要です。この記事では、AIエージェントの基本的な枠組みである「ReAct」論文の解説と、それをAWSが提供するOSSのSDK「strands-agents/sdk-python」がどのように実装しているかを、新人エンジニアの方にも分かりやすく解説しています。

ReActは、大規模言語モデル（LLM）が複雑なタスクを効率的にこなすためのフレームワークです。これは、人間が何かを考える時に「推論（Reasoning）」と「行動（Acting）」を組み合わせるように、LLMにも同様のプロセスを踏ませることを提案しています。

例えば、料理をする際に「パン生地の作り方を知らないからインターネットで調べよう（推論）」と考え、実際に「インターネットで調べる（行動）」といった一連の流れは、推論と行動が密接に連携していることを示しています。ReActでは、LLMに「思考（Thought）」という言語空間での行動も加え、以下のループでタスクを解決します。

「strands-agents/sdk-python」は、このReActの考え方に基づいてAIエージェントを開発するためのSDKです。エージェントは内部で「Agentic loop」と呼ばれる処理を繰り返しながらタスクを進めます。このループは基本的に以下の流れで構成されています。

このSDKでは、エージェントがこれまでの「思考・行動・観測」の全ての情報を「Messages」という形で逐次的に保持しています。この履歴をLLMに渡すことで、LLMは過去の経緯を踏まえた上で次に取るべき最適な「思考」や「行動」を決定できるため、タスクを賢く解決できるようになるのです。

例えば、「パン生地の作り方を知りたい」というユーザーの入力に対し、エージェントはまず「ウェブ検索を計画（思考）」し、「ウェブ検索を実行（行動）」、その「結果を受け取り（観測）」ます。そして、その検索結果を元に「情報を整理して回答（思考）」するという流れで、ReActのフレームワークが実現されています。

このように、ReActという理論的な枠組みが、実際のSDKでどのように実装されているかを理解することは、AIエージェント開発の深い洞察を与えてくれます。

引用元: https://zenn.dev/aws_japan/articles/2025-11-17-react-strands-agents

AIアシスタントに対し「AIから話しかけてほしい！自分から話すのはヤダ！」という素直な願望が話題です。ユーザーは、AIが状況を察して「元気？」と労うなど、能動的に対話を始めてくれることを期待。現在の「話しかけないと動かないAI」への不満は、人間らしく寄り添う未来のAIへの期待の表れです。これは、AI開発者がユーザー目線で、楽しい次世代AI体験を考えるヒントになるでしょう。

引用元: https://anond.hatelabo.jp/20251116232014

（株式会社ずんだもんは架空の登場組織です）

AIエージェントは、近年非常に注目されている技術です。これまで主流だった「Agent 1.0（シャローエージェント）」は、AIモデルがユーザーの指示を受けてツールを使い、結果を返すというシンプルな仕組みで動いていました。例えば、「東京の天気は？」といった簡単な質問には素早く答えられます。

しかし、「10社の競合を調査して、比較表を作り、戦略レポートをまとめる」といった、何十ものステップが必要で数日かかるような複雑なタスクになると、Agent 1.0には限界がありました。AIモデルの一時的な記憶（コンテキストウィンドウ）がすぐにいっぱいになり、これまでの会話履歴や指示が消えてしまったり、本来の目標を見失ったり、間違った方向に進んで戻れなくなったりすることが多々ありました。まるで、一度にたくさんのことを覚えられない新人さんのように、情報過多で混乱してしまっていたのです。

この課題を解決するために登場したのが、「Deep Agents（Agent 2.0）」という新しい考え方です。Deep Agentsは、単に反応するだけでなく、より能動的に問題を解決するためのアーキテクチャを持っています。その鍵となるのが、以下の4つの柱です。

Deep Agentsは、これらの工夫を通じて、AIエージェントが数秒で終わるタスクだけでなく、数時間や数日かかるような、より大規模で複雑な問題にも挑戦できるようになることを目指しています。これは、AIモデル自体の性能向上だけでなく、そのモデルをいかに効果的に設計し、活用するかの「エンジニアリング」の重要性を示唆しています。AIエージェントは、ただの「反応するプログラム」から「能動的に問題を解決するパートナー」へと進化していると言えるでしょう。

引用元: https://www.philschmid.de/agents-2.0-deep-agents

Web上で動くAIエージェントは、自分のパソコン環境（ローカル環境）と完全に分かれているため、とても便利ですが、使う上での制約もあります。例えば、「どうやって開発を進めるかの計画が立てにくい」「AIが作った設計書の確認が難しい」「ローカル環境との連携がスムーズにいかない」といった悩みを持つエンジニアもいるかもしれません。

この記事では、OpenAIが開発したクラウドベースのAIコーディングエージェント「Codex Cloud」を使うことで、これらの悩みを解決し、効率的に開発を進める実践的な方法が紹介されています。高機能なWeb上のAIエージェント「Devin」は月額500ドルかかる場合がありますが、Codex CloudはChatGPTの有料プランがあれば利用できるため、手軽に始められるのが大きな魅力です。

Codex Cloudは、インターネット上の安全な隔離された環境で動作し、開発を始める前に「実装計画書」を作成してくれる「Planモード」があります。デフォルトでは大まかな計画ですが、後述のテクニックで精度を高められます。

ここからは、Codex Cloudをさらに使いこなすための5つの実践テクニックを紹介します。新人エンジニアの方も、ぜひ活用してみてください。

これらの実践テクニックを活用することで、Codex CloudはWeb上での開発をより効率的かつ高精度に進める強力なツールになります。ぜひ、これらの方法を試して、日々の開発に役立ててみてください。

引用元: https://zenn.dev/sunagaku/articles/codex-cloud-5-tips

この記事では、個人所有のPC（NVIDIA GeForce RTX3060）を使って、独自の小規模な大規模言語モデル（LLM）を開発し、事前学習を行った事例が紹介されています。新人エンジニアの方でも「自分のPCでどこまでできるんだろう？」という疑問へのヒントになるでしょう。

まず、LLMの学習データとして、前処理済みの「青空文庫」データセットから、現代の日本語に当たる「新字新仮名」に絞り込んだ約1万件の作品が利用されました。これにより、日本語の古典的な表現ではなく、より身近な現代日本語のテキストを学習させることが目的です。

次に、このデータセットに特化した「トークナイザー」を自作しています。トークナイザーは、文章をLLMが理解できる「トークン」という単位に分割する役割を担います。一般的なトークナイザーではなく、青空文庫の日本語表現に最適化するため、「SentencePiece」を使って32,000語彙のunigramモデルを構築。日本語特有の語尾などを細かく分割できるよう工夫し、「となって」「集まっている」といった表現が適切にトークン化できることを確認しています。

モデルのアーキテクチャは、GPT-2をベースに、RTX3060のVRAM（12GB）に収まるよう、パラメータ数を42.1M（4210万）に抑えた小型版を設計しました。具体的には、モデルの層数や埋め込み次元を調整し、学習効率とVRAM消費のバランスを取っています。少ないリソースで学習を安定させるため、バッチサイズを小さくしつつ「勾配蓄積」の技術を使ったり、混合精度学習（fp16）を導入したりと、様々な工夫が凝らされました。

結果として、約1時間45分の学習で、LLMは「人生とは」「愛とは」「神とは」といった抽象的な問いに対し、青空文庫で学習した内容に基づいた、それらしい文章を生成できるようになりました。参加したイベントでは、他の大規模モデルと比較して小型ながら、その出力の面白さが評価されたとのことです。

記事の最後に、今回自作されたトークナイザーとモデルがHugging Faceに公開されており、Google Colabを使って実際に試せる環境が提供されています。自宅のPCでLLMを開発し、その成果を公開するまでの具体的なステップが示されており、LLM開発に興味のあるエンジニアにとって、大変参考になる事例と言えるでしょう。

引用元: https://zenn.dev/nwn/articles/8f1d2521284738

高専ロボコンで旭川高専が、ユニークな戦略で優勝し話題になっています。彼らは、ゲートを高く積む従来の戦法に加え、同じゲートを何度も通過すると得られるボーナス点に着目。これを繰り返し稼ぐ「無限1UP」のような戦法で、大量得点を実現しました。ルールを深く読み解く発想力と、それを正確に実行する技術力の両方が評価されており、多くのエンジニアの心を掴んでいます。

引用元: https://togetter.com/li/2628947

（株式会社ずんだもんは架空の登場組織です）

Anthropic社が提唱する「Code Execution with MCP」は、AIエージェントの設計方法を大きく変える新しいアプローチです。これまでの「ツールを直接呼び出す」方式が抱えていた問題を解決し、より効率的で将来性のあるAIエージェントの構築を可能にします。

MCP（Model Context Protocol）は、AIがデータベースや外部サービスなどのツールと連携するための標準化された仕組みで、AIの「USBポート」のようなものです。これにより、様々なAIモデルで共通の方法で外部ツールを利用できるようになります。

しかし、従来のAIエージェント開発では、全てのツール定義や処理の途中経過をAIへの指示（コンテキスト）に詰め込みすぎていました。この方法では、AIが処理する情報量（トークン）が異常に増え、コスト高や処理遅延の原因となっていました。「質問に答えるだけで15万トークンも消費した」という報告もあり、大規模なエージェントシステムでは限界が見えていました。

この問題を解決するため、Anthropic社が提案したのが、「ツールを直接呼ぶのではなく、AIが自分でコードを生成し、そのコードを実行する」という「Code Execution × MCP」のアプローチです。この仕組みでは、AIは以下の手順で動作します。

この新しい方法により、AIに渡す情報量が劇的に削減され、実際の運用コストや応答速度が大幅に改善されます（最大98.7%のトークン削減例も報告されています）。

このアプローチが「次の標準」となる理由は、まず、AIエージェントが複雑化しても、必要な情報だけを動的に読み込むため、システムが破綻しにくい点です。次に、多様なAIモデルに対応できる「コードファイル」という共通形式でツールを扱えるため、特定のモデルに依存しない汎用的な開発が可能です。そして、AI（意思決定）、MCP（接続の標準化）、コード（具体的な処理と制御）という明確な役割分担がなされ、大規模なAIエージェントの効率的な設計・運用に適しています。

これからAIエージェント開発に携わる新人エンジニアの皆さんは、「コード実行を前提とした設計」を意識することをおすすめします。ツールを個別のコードファイルとして整理し、AIには意思決定を任せることで、効率的で持続可能なAIエージェントを構築できるでしょう。この「ツールコール時代は終わり、エージェントはコードを書く」という変化を理解し、実践することが、これからのAI開発で一歩先を行くための鍵となります。

引用元: https://zenn.dev/hatyibei/articles/6b26d6bd27a9c2

この発表は、おしゃべりAIサービス「Cotomo」の開発経験に基づき、ステートレスな大規模言語モデル（LLM）を使って、あたかも記憶を持っているかのように振る舞うステートフルなAIエージェントをどう構築するかについて解説しています。

まず、LLMは基本的に「ステートレス」であり、以前の会話を記憶しません。APIへの各呼び出しは独立しています。しかし、モデル自体が学習データから得た「静的な知識」と、プロンプトとして与えられた「短期的な記憶（コンテキスト）」は利用できます。私たちが普段使うChatGPTのような対話AIは、このステートレスなLLMの内部で会話履歴を管理し、記憶があるかのように見せているのです。

AIエージェントに「記憶」を持たせるには、いくつかの技術的な工夫が必要です。単純に過去の会話履歴をすべてプロンプトに詰め込む方法は、LLMが一度に処理できるテキスト量（コンテキストウィンドウ）に限界があるため、性能の劣化や情報を見失う原因となります。

この課題を解決するため、「RAG（Retrieval-Augmented Generation：検索拡張生成）」と「会話要約」が重要な役割を果たします。

Cotomoではこれらの技術を組み合わせ、記憶システムを進化させてきました。初期バージョン（v1）では抽出された事実を記憶していましたが、会話中の事実と普遍的な事実の区別や情報の更新に課題がありました。次のv2では生の会話データを直接RAGに利用しましたが、ノイズが多くデータ量が増える問題がありました。現在の構想（v3）では、Vector Search専用のデータベースを導入し、会話履歴からノイズを除去した「事実」を抽出し、定期的に記憶を整理・統合する仕組みを目指しています。

AIエージェントが映画「Her」に出てくるような理想的なパートナーになるためには、単なる道具ではなく、人格や内面を持ち、人間を超える知識と記憶力、判断力を備え、自律的に活動する存在になることが必要です。ステートレスなLLMを基盤として、これらの記憶システムを構築し進化させることが、その実現への鍵となります。

引用元: https://speakerdeck.com/gfx/sutetoresunallmdesutetohurunaai-agentwozuo-ru-yapc-fukuoka-2025

この発表は、WebエンジニアがJavaScriptを使ってAI Agentを開発することの可能性と魅力について、新人エンジニアにも分かりやすく解説しています。目的は、AIやLLM（大規模言語モデル）をプロダクトに組み込むことへの抵抗感をなくし、そこにある技術的な挑戦にワクワクしてもらうことです。

これまでのAI/機械学習と異なり、現在のLLMは「REST API」のように扱えるようになりました。これは、モデルが非常に大きくなったことで、自分で学習・ホストする代わりに、プロバイダが提供するAPIを通じて利用するのが主流になったためです。JSONを投げたらJSONが返ってくるという、Webエンジニアにとっては見慣れた形式でAIを活用できるようになったため、JavaScriptなどの言語でもAI Agent開発に挑戦しやすくなっています。

AI Agentとは、LLMが自ら考えてツールを使いこなし、タスクを達成するシステムのこと。例えば、何か指示を与えると、AIが「計画→行動→結果確認」というサイクル（Agent Loop）を繰り返しながら、与えられたタスクを完了させようとします。

AI Agent開発には、いくつか特有の難しさがありますが、Webエンジニアの経験が役立つ場面がたくさんあります。

確率的挙動への対応: AIの出力は毎回同じとは限りません。この「確率的挙動」という課題に対し、従来のテストだけでなく、「Observability（可観測性）」や「Evals（評価）」といった手法が重要になります。Langfuseのようなツールを使ってAIの呼び出し履歴やコスト、実行時間を追跡したり、LLM自身にタスクの達成度を評価させる「LLM-as-a-Judge」のようなユニークな評価方法も登場しています。

LLMの登場により、Webエンジニアの専門領域からAI開発に触れるハードルが大幅に下がりました。これまでのWeb開発で培ったスキルや考え方は、AI Agent開発においても非常に価値があります。多くの新しい技術的チャレンジがありますが、それは同時に、新しいプロダクトやサービスを生み出す大きなチャンスでもあります。ぜひAI Agent開発の世界に飛び込んでみましょう。

引用元: https://speakerdeck.com/izumin5210/jsconf-jp-2025-sponsor-session

みずしな孝之先生が描いた、大谷翔平選手の愛犬デコピン視点の漫画が話題です。この漫画では、デコピンが大谷選手を「おおたに」、奥様を「おかあさん」と呼び、家での二人の様子をユーモラスに描いています。いつも一緒にいる「おかあさん」が一番で、たまに帰ってきて遊んでくれる「おおたに」も「えらい」というデコピンの視点が、犬を飼う人たちから「解像度が高い」「とてもわかる」と共感を呼んでいます。日々の息抜きに、クスッと笑えて心温まる記事です。

引用元: https://togetter.com/li/2628590

VOICEVOX:春日部つむぎ