NotebookOrigin

2026年9月11日時点で、OpenAIは「GPT-6 Sol」を正式発表していません。 一方、9月10日〜11日ごろから、「gpt-6-sol」というモデル名をOpenAI API上で目撃したという報告が出ています。 もしGPT-6 Solが実際に準備されているなら、注目したいのは「GPT-6 Astraより高性能なのか？」だけではありません。むしろ重要なのは、 非常に高性能なAstraに対して、Solがどのような役割を担うのか です。 仮にSolが性能・速度・効率のバランスを重視した主力モデルとして登場するなら、GPT-6時代は 「普段はSol、難しい仕事だけAstra」 という使い分けが合理的になる可能性があります。 この記事では、OpenAI公式情報と未確認情報を区別したうえで、GPT-6 SolとAstraの関係を考察します。 GPT-6 Solについて現在分かっていること まず、情報を整理しておきましょう。 項目 2026年9月11日時点 OpenAIによる正式発表 確認できず OpenAI公式モデル一覧 掲載なし 「gpt-6-sol」というモデル名 API上で目撃したとの報告あり 性能 未発表 API価格 未発表 コンテキスト長 未発表 利用制限 未発表 Reasoning仕様 未発表 2026年9月10日〜11日ごろから、Xなどで「gpt-6-sol」というモデル名がOpenAI API上に現れたという報告が見られるようになりました。 ただし、筆者が9月11日時点でOpenAI Developersの公式モデル一覧を確認した限り、「gpt-6-sol」は掲載されていません。 API内部でモデルIDが確認されたとしても、それだけで一般提供が始まったとは判断できません。テストや段階的な準備である可能性もあります。 したがって現段階では、 「GPT-6 Solがリリースされた」ではなく、「gpt-6-solというモデル名の目撃報告があり、新モデルが準備されている可能性がある」 と捉えるのが適切です。 GPT-6 Astraとは？「最難関の仕事」を狙うモデル GPT-6 Astraは、OpenAIが2026年9月3日に正式発表したモデルです。 OpenAIはAstraを 同社の「最も高性能なモデル」であり、最も難しいエンドツーエンドの仕事向け と位置づけて...

OpenAIが2026年7月に発表した「GPT-Live-1」は、ChatGPTの新しい音声体験を支えるモデルです。 特徴は、単に「音声でChatGPTと話せる」ことではありません。人間の話を聞きながら応答し、相づちを打ち、割り込みにも対応する リアルタイムな会話そのもの を担当するよう設計されている点です。 ただし、最初にAPIの提供状況を整理しておく必要があります。 2026年9月11日時点で、GPT-Live-1そのものを一般の開発者が指定して利用できるAPIモデルは、OpenAIの公式APIモデル一覧では確認できません。 OpenAIはGPT-Live発表時にAPI提供予定を案内しており、現在もGPT-Live-1のAPI提供通知を受け取るための登録ページを公開しています。 一方でOpenAI APIには、GPT-Realtime-2.1など、リアルタイムの音声入出力とTool Callingに対応したモデルがすでに存在します。 つまり、「リアルタイム音声エージェントをAPIで作る」という世界自体はすでに始まっています。そのうえでGPT-Live-1が示している設計思想を見ると、今後の音声AIがどこへ向かうのかがかなり分かりやすくなります。 この記事で特に注目したいのは、次の考え方です。 GPT-Live-1は、すべての仕事を単独で処理するAIというより、人間とのリアルタイムな会話を担当する「フロントエンドAI」として考えると分かりやすい。 「会話するAI」と「仕事をするAI」を分け、それらを組み合わせる。この構成が、これから音声AIサービスを考えるうえで重要になりそうです。 1. GPT-Live-1とは？ GPT-Live-1は、OpenAIが2026年7月に発表したGPT-Liveシリーズの音声モデルです。ChatGPTでは有料ユーザー向けの音声モデルとして導入されています。 大きな特徴が Full-duplex（全二重） です。 これは簡単に言えば、AIが「聞く」と「話す」を同時に扱える仕組みです。 従来の音声AIでは、人間が話し終わってからAIが考え、AIが話し終わってから再び人間が話す、というターン制になりがちでした。 GPT-Liveでは入力を受けながら出力を生成し続け、「話す」「聞き続ける」「少し待つ」「割り込みに対応する」「ツールを呼ぶ」と...

Claude CodeやCodexのようなコーディングエージェントは、コード生成だけでなく、要件整理、設計、実装、レビュー、テストといった開発工程にも利用できます。 さらに、工程ごとに役割を分け、前工程の成果物を次の担当へ渡すことで、複数のAIを1つの開発チームとして動かすこともできます。この記事では、この仕組みを「AIチーム」と呼びます。 今回は、ログイン機能や生成AIによる回答機能を持たないシンプルな「社内FAQ Webアプリ」を題材にします。HTML、CSS、JavaScript、JSONを中心とした小規模なPoCとして、Web開発側では追加費用をできるだけかけずに試せる構成です。 開発工程を 要件整理 → 設計 → 実装 → レビュー → 修正 → テスト → 統合 に分解し、AIに開発工程そのものを分業させる方法を見ていきます。 1. AIチームの基本構造 今回の開発では、統括、要件整理、設計、実装、レビュー、テストという役割に分けます。分離するのはAIの人数そのものではなく、責任とコンテキストです。 役割 主な仕事 成果物 統括 タスク分解、進捗管理、工程間の調整 タスク、最終成果物 要件整理 必要な機能と制約を整理 requirements.md 設計 画面、データ、処理を設計 design.md 実装 設計をコードへ変換 ソースコード レビュー 要件・設計と実装を照合 レビュー結果 テスト 動作と要件充足を確認 テスト結果 小規模なPoCなら、すべてを別エージェントとして常時起動する必要はありません。同じエージェントでも役割を切り替えられます。一方、複数エージェントを利用できる環境では、依存関係の少ないタスクを分離して進めることもできます。 2. 今回作る社内FAQアプリ PoCでは、FAQ一覧、キーワード検索、カテゴリ絞り込み、FAQ登録・編集・削除を実装します。ログイン、本格的なデータベース、生成AIによる回答機能は対象外です。 技術構成はHTML、CSS、JavaScript、JSONとし、AIチームの開発ワークフローを確認することに集中します。 3. 成果物を受け渡すフォルダを作る faq-poc/ ├── data/ │ └── faq.json ├── docs/ │ ├── requirements.md │ └── des...

AIエージェントを本格的に使い始めると、仕事のボトルネックが変わってきます。 以前は「情報を探す」「資料を読む」「コードを書く」「文章を書く」ことに多くの時間を使っていました。Claude CodeやCodexのようなエージェントを使えば、この部分はかなり高速化できます。 ところが、そこで仕事が終わるわけではありません。むしろ次に、もっと厄介な仕事が残ります。 「で、どれを信じるのか？」 AIが短時間で大量の情報を集められるようになれば、人間が一件ずつ検索する必要は減ります。しかし、「この情報源は信用できるのか」「これは現在も有効なのか」「一次情報なのか、誰かの解釈なのか」「複数の情報が矛盾しているが、どちらを採用するのか」「AIが作った複数案のうち、本番環境へ入れていいのはどれか」という仕事は残ります。 これからは、人間の時間のかなりの部分が、この 判断 に使われるようになるのではないかと思っています。 だからClaude Code、Codex、Obsidianを組み合わせて作るべきものは、単なる「第二の脳」ではありません。必要なのは、 情報の出所、鮮度、検証状態、採用状態まで管理できるナレッジシステム です。 情報をたくさん与えればAIは賢くなる、という誤解 最初に陥りやすいのが、「AIに情報をたくさん与えれば、それだけ賢くなる」という考え方です。 会議メモ、設計資料、過去の意思決定、技術調査、障害対応、AIとの会話。全部Obsidianへ保存して、Claude CodeやCodexからアクセスできるようにする。一見すると理想的です。 しかし、情報が増えてくると問題が起こります。2024年の調査ではA、2025年にはB、2026年にはC。でも昔のAも検索すると出てくる。 AIにとって難しいのは、情報を「見つける」ことではありません。 見つけた情報の中から、今どれを信じるべきか判断すること です。 長大なドキュメントより「地図」を作る そこで最初に必要になるのが、ナレッジの分割です。 巨大な knowledge.md に何でも詰め込むのではなく、 architecture.md 、 security.md 、 decisions.md 、 operations.md 、 current-stack.md のように意味のある単位へ分け、Obsidianの [[Wik...

前回は、ObsidianをCodexの「外部記憶」として使う方法を紹介しました。 次の段階では、単にCodexがVaultを読むだけでは足りません。 重要なのは、 必要な知識をCodex自身が選ぶこと 、 古い情報を避けること 、 確認済みの事実だけを使うこと 、そして 使い終わった知識を再利用可能な形で戻すこと です。 ここまで来ると、Obsidianは単なるノート置き場ではなく、Codexが利用する「知識基盤」に変わります。 上級編のゴール 目指す構成は次の通りです。 Sources → Research → Decisions → Codex → Drafts → Published さらに、Codexは依頼内容に応じて必要なノートだけを読みます。 人間が毎回ファイルを指定する 状態から、 Codexが自分で読むべき知識を判断する 状態へ進化させます。 1. VaultをAI向けに分ける おすすめ構成は次の通りです。 Sources/ ：原資料や一次情報 Research/ ：確認済みの事実や調査結果 Decisions/ ：過去に何を選び、なぜそう判断したか Drafts/ ：生成中の文書 Published/ ：完成済みの成果物 TODO/ ：未確認事項や追加調査 この構成にすると、Codexにルーティングルールを持たせやすくなります。 2. frontmatterで「知識の品質」を管理する Markdownの先頭にメタデータを持たせます。 --- type: research topic: pixel status: verified updated: 2026-08-15 expires: 2027-02-15 source_count: 5 confidence: high --- Codexには、「 status: verified で、 expires を過ぎていないResearchだけ使う」と指示できます。 これで古いノートを誤って使うリスクを減らせます。 3. Decisionsフォルダが意外と重要 Researchには事実を保存します。一方、Decisionsには判断を保存します。 Pixel 11 Proを推した理由 なぜこのSEOタイトルにしたか なぜこの構成を採用し...

Codexを使っていると、次第に「毎回ゼロから情報を渡すのはもったいない」と感じるようになります。 過去に調べたこと、技術メモ、判断した理由、失敗した手順、記事の下書き、製品比較。こうした情報を毎回プロンプトへ貼り付けるのではなく、 Codexが必要なときに自分で読みに行ける知識ベース を用意できれば、かなり効率が上がります。 そこで相性がいいのがObsidianです。 ObsidianのVaultは特殊なデータベースではなく、Markdownファイルが入った普通のフォルダです。Codexから見れば、そのまま「検索できる・読める・編集できる作業データ」になります。 つまり、今回の主役はObsidianではありません。 Codexをより少ない説明で動かすために、Obsidianを外部記憶として使う。 これがこの記事の基本的な考え方です。 さらにNotebookLMを加えると、 NotebookLMで大量の原資料を読み、Obsidianへ整理済みの事実を保存し、Codexが必要な情報だけを使って最終生成する という役割分担もできます。 結論：ObsidianをCodexの「外部記憶」にする CodexとObsidianを組み合わせるために、必ずしも専用プラグインが必要なわけではありません。 Obsidianのノートは .md ファイルとして保存されています。 たとえばWindowsでVaultが次の場所にあるとします。 C:\Users\ユーザー名\OneDrive\Obsidian\MyVault この MyVault をCodexの作業対象にすれば、その中のMarkdownをCodexから読み取ったり、編集したりできます。 Codex ← Obsidian Vault → 人間 同じ知識ベースを、人間はObsidianから、AIはCodexから扱う構成です。 Codexに外部記憶があると何が変わる？ 通常はCodexへ「前回こういう調査をした」「この記事ではこの条件を使う」「この数値はこの資料が根拠」と毎回説明する必要があります。 しかし、それらをObsidianへ保存しておけば、たとえば次のように指示できます。 「Research/Pixel11_2026.mdを読んで記事を書いて」 毎回長い背景説明を書く必要が減り、...