youtube版(スライド付き)

関連リンク

• Building more with GPT-5.1-Codex-Max

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

何が新しいの？
このモデルの最大の進化は、「Compaction（コンパクション）」という新しい技術によって、「長時間の詳細な作業」をこなせるようになった点です。これまでのAIは、一度に扱える情報量（コンテキストウィンドウ）に限りがあり、長い時間のかかる複雑なタスクでは途中で「あれ？何してたっけ？」となってしまうことがありました。
しかし、GPT-5.1-Codex-Maxは、まるで人間がメモを取りながら考えるように、必要に応じて過去の情報を整理・圧縮することで、何百万ものトークンを扱う大規模なプロジェクトのリファクタリングや、数時間にわたるデバッグセッション、さらには自律的なエージェントループまで、途切れることなく作業を続けられるようになりました。社内評価では24時間以上も独立して作業し、テストの失敗修正までこなした例もあるそうです。

開発体験はどう変わる？

• 高速・高効率・低コスト: より少ないトークンで高い性能を発揮するため、開発コストの削減にも繋がります。例えば、高品質なフロントエンドデザインを、以前より低いコストで作成できるようになりました。


• 実践的な開発作業に強い: PR（プルリクエスト）の作成、コードレビュー、フロントエンドコーディング、Q&Aなど、実際のソフトウェア開発現場で必要とされるタスクに特化して学習されています。なんと、Windows環境での動作にも対応しました。

利用方法と注意点
GPT-5.1-Codex-Maxは、現在、CodexのCLI（コマンドラインインターフェース）、IDE（統合開発環境）拡張機能、クラウド、コードレビューなどで利用可能です。APIアクセスも近日提供予定です。
ただし、AIエージェントの利用にはいくつかの注意点があります。

• 人間による確認の重要性: AIが生成したコードやレビュー結果は、最終的には人間が確認し、承認することが非常に重要です。AIはあくまで強力な「共同作業者」であり、人間の「代替」ではありません。


• セキュリティ: Codexはデフォルトで安全なサンドボックス環境で動作しますが、インターネットアクセスなどを有効にする場合は、プロンプトインジェクションなどのリスクに注意が必要です。

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

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

• LLMで業務ワークフローを自動生成・最適化する! 〜ワークフロー自動生成・最適化の取り組みについて〜

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

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

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

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

1. 1ページずつテキスト化（Python）: PDFから各ページをテキストデータに変換。


2. 重要ページを判定（LLM）: 300ページの中から、必要な情報が含まれる「重要ページ」をLLMが判定。これを30ページ程度に絞り込み、LLMが一度に処理できる情報量に調整する工夫が自動で発見されました。


3. 重要ページを選択・結合（Python）: 判定された重要ページを結合し、次のステップへ渡します。


4. データを抽出（LLM）: 結合されたテキストから、LLMが数値を抽出します。ここでは「計算は禁止」と明確に指示し、LLMには情報の「読み取り」に集中させます。


5. 合計値を計算（Python）: 抽出された数値を使って、Pythonコードで正確な計算（合計値、差異、密度など）を行います。


6. 単位を正規化（Python）: 最終的なデータ形式に合わせて、単位などを調整します。

このワークフローは、大規模なデータ処理において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）」について、その理想と現実、そして現場での向き合い方が解説されています。新人エンジニアの方にも理解しやすいように、要点をまとめました。

1. 仕様駆動開発（SDD）とは？

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

2. SDDの理想とメリット

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

• 手戻りの削減: 事前に明確なSpecがあるため、実装段階での認識のズレが減ります。


• 設計レビューの負担軽減: Specが構造化されているため、設計内容の理解が容易になります。


• 並行開発の促進: 各機能のSpecが独立していることで、複数のチームやエンジニアが並行して開発を進めやすくなります。


• 品質とスピードの向上: Spec作成からレビュー、実装、テスト、フィードバックのサイクルがAIによって高速化され、高品質なソフトウェアを迅速に顧客に届けられるようになります。


• 「検証可能性」と「フィードバックループ」: Specの振る舞いが自動テストと結びつき、実装の正確性が検証されます。また、Specは一度作ったら終わりではなく、開発を通じて改善されていくものと捉えられています。

3. SDDの現実と課題

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

• ツールの未成熟: 現在のSDDツールやLLM（大規模言語モデル）の性能は、SDDの理想に完全に追いついていません。


• Specの巨大化とレビューの負荷: AIが生成するSpecが大きくなりすぎることがあり、人間によるレビューに膨大な時間がかかってしまうことがあります。


• 正確性の検証: LLMは確率的に出力をするため、Spec通りに完璧なコードが生成されるとは限りません。この課題に対し、Kiroというツールでは「Property-based tests（プロパティベースドテスト）」という、システムの振る舞いの一般則をランダムな大量データで検証する手法が導入されています。


• チーム・組織全体での変革の必要性: SDDはエンジニアだけでなく、プロダクトオーナー（PO）やプロダクトマネージャー（PM）、QAエンジニアなど、開発に関わる全ての関係者がSpecを中心に連携し、組織全体の開発プロセスを変える必要があります。

4. SDDとの賢い向き合い方

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

• 開発基盤の整備: CI/CD（継続的インテグレーション/デリバリー）などのDevOps環境を整え、システムの評価・検証サイクルがスムーズに回る状態にしておくことが大切です。また、システム全体をモジュール性の高い、分かりやすい設計にすることも重要です。


• 適材適所での活用: SDDは、仕様が安定しており、明確な境界を引きやすい機能（例: 外部APIとの連携、データベースの設計、金融計算ロジックなど）に向いています。未知の要素が多いタスクや、ごく小規模なタスクには、必ずしも最適ではない場合もあります。


• 小さく始める: 自社の開発プロセスやチームの状況に合わせて、必要最小限のSpecから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

• お便り投稿フォーム

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