NotebookOrigin

GPT-6 Astraを使い始めて最初に気をつけたいのは、「Astraを選んだら、その仕事全部をAstraにやらせる」という使い方です。 Astraは、複雑な推論、コーディング、調査、コンピューター操作など、特に難しい作業に向いた高性能モデルです。一方、WorkやCodexでは、同じタスクでも選択するモデル、入出力の大きさ、Reasoning、Fast mode、処理ステップ数などによって利用量が変わります。 実際に使っていると、「1回依頼しただけなのに、思った以上に利用量が減った」という状況は起こり得ます。 ただ、対策は単純に「Astraをなるべく使わない」ではありません。 「Astraで実行できるか」ではなく、「Astraでなければ困るか」で判断する。 Astraを選んだからといって、タスク全体をAstraで処理する必要はありません。難しい判断だけAstraに任せ、それ以外はLuna、Terra、Solへ分ける。そのために必要なのが、この記事でいう「Astraガードレール」です。 なぜAstraで利用量が膨らむのか 問題は、Astraへの1回の回答が単純に「何倍も高い」という話だけではありません。 むしろ注意したいのは、エージェント型のタスクでは1件の依頼から大量の「行動」が発生することです。 大きなタスクを分解せず丸ごと渡す リポジトリ全体を探索する Reasoningを常に高くする Web検索を何度も行う 複数のサブエージェントへ仕事を広げる 同じ方法で何度も再試行する 「念のため」という理由で追加調査する 本来の依頼とは無関係な改善まで始める こうした挙動が重なると、一つひとつは妥当そうな行動でも、合計の利用量は大きくなります。 OpenAIの利用量ガイドでも、大きな入出力、高いReasoning、Fast mode、複数ステップのタスクなどが利用量へ影響し得ると案内されています。 つまり、Astra対策では「何トークンまで」と考えるだけでは足りません。 トークンを大量に使う原因になる行動そのものを制御する 必要があります。 「Astraでなければ困るか」でモデルを決める モデルは、単純な「弱い→強い」の順番として使わない方が効率的です。それぞれに担当する仕事を決めます。 モデル 主に任せる仕事 Luna 情報抽出、分類、ファイル検索、一覧化、フォーマット...

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を読んで記事を書いて」 毎回長い背景説明を書く必要が減り、...

NotebookLMで集めた資料を、Codexから参照・整理できるようにしたい場合は、カスタムMCP（Model Context Protocol）として接続する方法があります。 この記事では、コミュニティ製の notebooklm-mcp-cli を使い、WindowsのChatGPTデスクトップアプリ（Codex）へNotebookLMを接続する手順をまとめます。 注意: この連携はGoogleおよびOpenAIの公式連携ではありません。NotebookLMの内部APIやブラウザの認証情報を利用する仕組みのため、機密性の高い資料では使わないことをおすすめします。 できること NotebookLMのノートブックを一覧表示する ノートブック内の内容を質問・要約する URLやテキストなどをソースとして追加する 音声概要、レポート、スライドなどの作成を依頼する 事前準備 Windows PC ChatGPTデスクトップアプリ（Codex） NotebookLMを利用できるGoogleアカウント 1. uvをインストールする PowerShellを開き、次のコマンドを実行します。 winget install --id astral-sh.uv -e 完了したら、PowerShellを一度閉じて開き直します。 2. NotebookLM用CLI／MCPをインストールする uv tool install --python 3.12 notebooklm-mcp-cli インストールされる主なコマンドは以下です。 nlm : NotebookLMを操作するコマンドラインツール notebooklm-mcp : CodexなどのAIクライアントと接続するMCPサーバー 3. Googleアカウントで認証する nlm login ブラウザが開くので、NotebookLMで利用しているGoogleアカウントにログインします。認証状態は次のコマンドで確認できます。 nlm login --check 4. CodexにカスタムMCPとして登録する ChatGPTデスクトップアプリで、次の順に設定します。 設定を開く MCP servers を選ぶ Add server を選ぶ 種別として STDIO を選び、MCPサーバーのコマンド...