AI – gonta

単なるテキスト検索からの脱却。「OKF対応」で進化したGraph RAGがAIに伝える立体的コンテキスト

Sat, 25 Jul 2026 07:11:14 +0000

前回、Obsidianのデータを独立したRAGとしてMCP化し、あらゆるAIから横断検索できる「最強のマルチAI手帳」について解説しました。
今回は、そのアーキテクチャの次なる進化である「OKF（Open Knowledge Format）への対応」と「Graph RAG化」について深掘りします。

なぜ従来のRAGは「平面的」なのか？

一般的なRAGシステムでは、Markdownなどのテキストファイルを適当な長さ（チャンク）に分割してベクトル化し、AIに渡します。
しかし、これには大きな欠陥があります。AIは「検索にヒットしたテキストの断片」を受け取るだけで、「そのノートがどのプロジェクトに属しているのか」「どんな他のタスクと関連しているのか」といった『文脈の繋がり』を理解できないのです。

Google提唱の「OKF」を取り入れた解決策

そこで今回、Googleが提唱する「OKF（Open Knowledge Format）」の概念をObsidianの運用ルールに導入しました。
これは、情報を単なるテキストの羅列ではなく、「YAMLの構造化データ（メタデータ）」＋「Markdown本文」として扱うアプローチです。

具体的には、Obsidianのノートの先頭にプロパティ（YAML）を持たせ、明示的にエッジ（関係性）を記述します。

---
parent: "[[AIエージェント開発プロジェクト]]"
type: "task"
---

Graph RAGがAIに伝える「立体的な知識」

裏側で動いている自作のインポーター（Watcher）を改修し、このYAMLフロントマターから parent や related といったプロパティを抽出し、意味付きのエッジ（関係性の型） としてSQLite（Graph DB）に記録するようにしました。

そして、MCPサーバー経由でAIが検索を行った際、単にヒットしたテキストを返すだけでなく、以下のような「ナレッジグラフ構造（トポロジー）」を文字列の先頭にマッピングしてAIに渡します。

【ナレッジグラフ構造 (Knowledge Graph Topology)】
[現在のタスク] --(parent)--> [AIエージェント開発プロジェクト]
[現在のタスク] --(link)--> [関連技術メモ]

【コンテンツ詳細 (Content)】
...（ノート本文）...

AIが文脈を「理解」し始めた

この改修を行った結果、MCPを利用するAIエージェント（GonrasやAntigravity等）の推論能力が劇的に向上しました。
キーワードのマッチングだけでなく、「このタスクはあのプロジェクトの子タスクだから、全体のスケジュールに関わるな」といった、手帳内の立体的なつながり（Graph Topology）を認識した上で回答してくれるようになったのです。

単なる「AI×Obsidian」の連携から一歩進み、自分自身の脳内のリンク構造をそのままAIにインストールする。これこそが、次世代のパーソナルAIの最適解だと確信しています。

単なるObsidian×AI連携ではない。「RAGのMCP化」が創る最強のマルチAI手帳

Mon, 20 Jul 2026 11:29:30 +0000

最近、「Obsidian（ローカルMarkdownメモ）をAIと組み合わせる」というアプローチが世間で流行っています。しかし、私が今回最もこだわり、そして到達した結論は単なる連携ではありません。
それは、「Obsidianの情報をRAG（検索拡張生成）システムとして独立させ、さらにそれをMCP（Model Context Protocol）化する」という設計です。

このアーキテクチャにより、私のObsidianは単なるメモ帳から、あらゆるAI（市販のAIツールや自作のAIエージェント）から共通して参照できる「My手帳（汎用ナレッジベース）」へと進化しました。

構成図（アーキテクチャ）

graph TD
    subgraph Obsidian_Vault [Obsidian Vault]
        NOTES[" My手帳 (Obsidian)
日々の記録・アイデア"]
    end

    subgraph Unified_RAG_MCP [Unified RAG MCP - Raspberry Pi]
        WATCHER[" Watcher
(3分待機で自動ベクトル化)"]
        VECTOR_DB[(" SQLite Vector DB
(Gemini Embeddings)")]
        MCP_SERVER[" MCP Server
(RAG検索APIを提供)"]

        NOTES -.->|ファイル更新検知| WATCHER
        WATCHER -->|見出しベースで高速チャンク化| VECTOR_DB
        VECTOR_DB <-->|検索リクエスト| MCP_SERVER
    end

    subgraph AI_Clients [AI Clients - マルチアクセス]
        ANTIGRAVITY[" Antigravity
(最先端のMCP対応AI)"]
        GONRAS[" Gonras
(日々の対話をこなす独自AI)"]

        ANTIGRAVITY <-->|ツールとしてRAGを呼び出し| MCP_SERVER
        GONRAS <-->|ツールとしてRAGを呼び出し| MCP_SERVER
    end

一般的なObsidian×AIの限界

よくある構成は、Obsidianのプラグインを使ってChatGPTを呼び出したり、特定のAIアプリにObsidianのフォルダを読み込ませたりするアプローチです。
しかしこれでは、「その特定のAI」からしか手帳を使えません。また、巨大な手帳データを毎回AIに読ませるのは非効率であり、すぐにコンテキスト（記憶枠）の限界に達してしまいます。

私がこだわった「RAGのMCP化」というブレイクスルー

そこで私は、Obsidianのデータを外部のRAG（ベクトルデータベース）として独立させました。
さらに、そのRAGシステムを話題のMCP（Model Context Protocol）サーバーとして包み込みました。これが最大のポイントです。

これにより、以下のような「マルチAIアクセス」が可能になりました。

独自AIエージェント（Gonras）からの利用
私が自作したAIエージェント「Gonras」は、私と会話する中で「あ、これは手帳に書いてあったな」と思えば、MCP経由でRAGを検索し、文脈を踏まえた返答をしてくれます。
最先端AIツール（Antigravity等）からの利用
GeminiやClaudeなどの最先端モデルを搭載したMCP対応ツールも、この「My手帳MCP」を接続するだけで、初対面なのに私の個人的な知識や背景（サーバーの設定から自転車の趣味まで！）をすべて理解したアシスタントに早変わりします。

究極の「My手帳」エコシステムの完成

人間はただObsidianにメモを書くだけ。
裏側（Watcher）がそれを自動で高速にチャンク化（意味段落に分割）し、ベクトルDBを更新。
MCPを通じて、どんなAIエージェントも瞬時にその知識を引き出せる。

AIの進化は日進月歩で、明日にはもっと賢い新しいAIモデルが登場するでしょう。
しかし、この「RAGのMCP化」というアーキテクチャを組んでおけば、AIモデルがどれだけ変わろうと、「自分の脳（Obsidian）」をプラグのように新しいAIへ挿し込むだけで済みます。

これこそが、情報過多の時代を生き抜くための、真にポータブルで無敵な「My手帳」の姿です。

株価自動売買のための基盤づくり ― 構想と現在の作成状況

gonta — Wed, 04 Mar 2026 13:48:47 +0000

はじめに

株価の自動売買を実現するには、「データの取得」「分析」「可視化」「注文実行」を一貫して扱う基盤が必要です。本記事では、それらを複数サービスに分離した構成で自作しているプロジェクトの構想と、現時点での実装状況をまとめます。個人の学習・検証用途を想定しており、本番の自動売買に至るまでの道のりを記録する目的です。

構想

全体像

自動売買の基盤を次のように整理しています。

レイヤー	役割
データ取得	株価・出来高・先物・ADR などを定期・手動で取得し、DB に蓄積する
分析	蓄積データから市場の強弱・業界ランキング・異常出来高などを算出する
可視化・API	チャート表示や監視銘柄一覧を提供し、他システムから参照できる API を提供する
注文実行	証券会社 API と連携し、成行・指値の注文や保有銘柄の同期を行う

データベースは TimescaleDB（PostgreSQL 系） を中核に置き、各サービスが DB または HTTP API 経由で連携する形を想定しています。将来的に「シグナル生成 → 注文」を自動化する戦略エンジンを載せる土台として、まずは取得・分析・表示・注文の各機能を独立したサービスとして実装し、組み替えや拡張がしやすいようにしています。

技術選定

言語: Rust（パフォーマンスと型安全性を重視）
Web フレームワーク: Axum
DB アクセス: SQLx
時系列データ: TimescaleDB のハイパーテーブルで株価を保存

現在の構成（サービス一覧）

サービス名	主な役割	備考
stock_get	株価・先物・ADR の取得、監視銘柄管理、スケジューラー	株価取得専用。Web UI 付き
stock_tran	証券会社（立花証券）API 連携、注文送信・保有同期	デモ/本番モード切替あり。現状は安全のため本番注文は無効化
stock_view	株価チャート表示、監視銘柄一覧、データ可視化、外部 API	読み取り専用ビューア＋API サーバ
stock_analyze	風読みシナリオ・業界ランキング・異常出来高アラート	分析結果を REST API で提供
mcp	銘柄検索・板情報など MCP ツールから API を利用	エージェント連携用

各サービスは別ポートで起動し、必要に応じて他サービスの API や共有 DB を参照します。

chat から MCP 経由でアクセス

この基盤には、chat（例: Cursor のチャットなど）から MCP（Model Context Protocol） 経由でアクセスすることもできる。MCP サーバーが stock_get や stock_view の API を呼び出すツールを提供しており、チャット画面から監視銘柄一覧の取得・銘柄検索・板情報の参照などを自然言語で依頼できる。将来的には注文の実行も MCP 経由で行えるようにする想定だ。

作成状況

1. stock_get（株価取得システム）

状況: コア機能は実装済み。

監視銘柄管理: Web UI で銘柄の追加・削除・更新。複数時間足（日足・週足・月足）に対応。
株価データ取得: Stooq API をメインに使用（無料・認証不要）。J-Quants API・Yahoo Finance API はフォールバック・補完用として仕様はあるが未実装。
データカバレッジ管理: 銘柄・時間足ごとの連続取得期間を管理。Web UI で横棒グラフ表示。
スケジューラー: 指定時刻（既定 19:00）に全監視銘柄の株価を一括取得。平日のみ実行オプションあり。
その他: 先物（Twelve Data）、ADR（Yahoo）、日経平均株価（Yahoo）の定期取得スケジューラーあり。

2. stock_tran（注文・保有同期）

状況: 立花証券 API 連携の基本は実装済み。注文はデモ環境でのみ有効。

認証・セッション: ログイン・セッション維持。テストモードフラグでデモ/本番を切替。
保有銘柄同期: API から取得した保有一覧を DB に反映。Web UI で表示。
注文送信: 成行・指値、買い・売りを API で送信可能。本番環境では意図的に注文送信を無効化しており、テストモード時のみ動作。
注文履歴: 送信した注文を DB に記録し、一覧取得 API を提供。

本番で自動売買を行う場合は、別途「戦略エンジン」から注文 API を叩く形を想定しており、その前にリスク管理・約定確認フローなどの検討が必要です。

3. stock_view（表示・外部 API）

状況: 表示機能と外部 API は実装済み。株価チャート（複数銘柄・時間足・期間選択）、監視銘柄一覧、データ取得状況のヒートマップ、API キー認証・レート制限付きの外部 API（MCP や他ツールから利用可能）。

4. stock_analyze（分析）

状況: 3 機能とも実装済み。風読みシナリオ（日経先物から市場の強弱）、業界ランキング（ADR から業界リーダーの寄付き状況）、異常出来高アラート。いずれも REST API で結果を返し、自動売買の「シグナル」の入力として利用する想定です。

今後の予定（イメージ）

戦略エンジン: 分析結果や株価データを入力にシグナルを生成し、stock_tran の注文 API を呼び出すコンポーネント。ルールベースやバックテストを検討中。
本番注文の有効化: リスク管理・約定確認・障害時のフォールバックを設計したうえで判断する予定。
J-Quants / Yahoo の実装: stock_get のフォールバック・補完データ源として実装し、取得の安定性を高める。

まとめ

項目	内容
目的	株価の自動売買を実現するための基盤を、取得・分析・表示・注文に分離して構築している
現状	データ取得・注文・保有同期・表示・API・分析まで一通り実装済み。注文はデモ環境のみ有効
次のステップ	戦略エンジンの設計・実装と、本番注文を有効にするかどうかの判断

まだ「自動で売買が回る」ところまでは至っておらず、基盤ができつつある段階です。進捗に応じてまた記事を更新する予定です。

作成日: 2026年3月

OpenAI APIを使った時に備忘録メモ

gonta — Sun, 31 Aug 2025 07:29:27 +0000

OpenAIの基本的な使い方を備忘録として記載。

Toolsを使った呼び出し例

async def process_conversation(user_input: str):
# 1. メッセージの準備
messages = [
{
“role”: “system”,
“content”: [
{“type”: “input_text”, “text”: “システムプロンプト”}
]
},
{
“role”: “user”,
“content”: [
{“type”: “input_text”, “text”: user_input}
]
}
]

# 2. API呼び出し（ツール使用）
response = client.responses.create(
model=ai_config[“model”],
input=messages,
tools=tools,
tool_choice=”auto”
)

# 3. 完了まで待機
while response.status != “completed”:
if response.status == “failed”:
return {“message”: f”エラー: {response.error}”}
# 待機処理

# 4. ツール呼び出しの処理
tool_calls = []
if response.output:
for tool_call in response.output:
if tool_call.type == “function_call”:
tool_calls.append(tool_call)

# 4-1. ツール実行のループ処理
max_tool_iterations = 7 # 最大ツール実行回数
tool_iteration_count = 0

while tool_iteration_count < max_tool_iterations and tool_calls:
# ツール実行処理
for tool_call in tool_calls:
# 重複実行チェック
if tool_call.call_id not in processed_tool_calls:
# ツール実行と結果格納
# … (詳細は「ツール実行の処理」セクションを参照)
processed_tool_calls.add(tool_call.call_id)

tool_iteration_count += 1

# 次のツール呼び出しを確認
if tool_iteration_count < max_tool_iterations:
# 再度API呼び出ししてツール呼び出しを確認
response = client.responses.create(
model=ai_config[“model”],
input=messages,
tools=tools,
tool_choice=”auto”
)
# 完了まで待機
while response.status != “completed”:
if response.status == “failed”:
return {“message”: f”エラー: {response.error}”}

# 新しいツール呼び出しを確認
tool_calls = []
if response.output:
for tool_call in response.output:
if tool_call.type == “function_call”:
tool_calls.append(tool_call)

# 5. 最終回答の取得（ツール使用なし）
final_response = client.responses.create(
model=ai_config[“model”],
input=messages,
tools=tools,
tool_choice=”none”
)

# 6. 最終回答の処理
while final_response.status != “completed”:
if final_response.status == “failed”:
return {“message”: f”最終回答取得エラー: {final_response.error}”}

# 最終回答を結果に格納
result = {}
if final_response.output and len(final_response.output) > 0:
result[“message”] = final_response.output[-1].content[0].text
else:
result[“message”] = “回答を取得できませんでした”

return result

自分専用AIエージェント作成計画

gonta — Sun, 13 Jul 2025 02:53:30 +0000

Mark0　（1994）

脳の神経細胞の動きをシミュレーションをし、３層のニューラルネットワークを作成。教師信号を用意し単純なモデルの学習を始める。

Mark1 OpenAI APIを使う（2024年～）

PythonからOpenAI APIを使って、会話形式でやり取りを実現

どのAIも最新情報での学習は行われていなく最新の情報について答えられない状況だったが、OpenAIから外部ツールを呼べるようなり、そこで様々な最新情報を入手できるようになった。早速その外部ツールを呼び出す機能を使って、現在の時間、現在の天気予想、地名から経度・緯度を変換するツールを登録。

Mark2 Discord経由でOpenAI APIを使う

Pythonを起動しコマンドプロンプトで会話をしていが、外出先でも利用ができるように仕様変更を検討。

LineとPython の連携を考えたが、LineAPIは一定の件数を超えたら有料。そのため無料のDiscordのボットに、本AIエージェントを登録（自分専用）。これでリモートからのやりとりが可能になる。

Mark2.1 OpenAI APIから外部ツール（外部API）を使う

外部ツールで取得できる情報が限定的なため外部検索エンジンと連携ができるように検討。
GoogleAPIを使って、Google検索を本AIエージェントから直接利用できるようにし、取り扱える情報の強化に成功

Mark2.2 OpenAI APIで永続的な会話を成り立たせる

OpenAIのAPIは、セッション内であれば、一定期間の会話は覚えているが、一定期間を超えたりセッションを新規に作成（または、プログラムの再起動）をすると、毎回初めましてといった状態になる。
OpenAI APIで取得したデータは学習には使わないということ（2025年7月現在）なので、これを避けるために、過去の会話を会話のたびに追加するように実装。過去に会話した内容もすべての記録されているため、割と矛盾なく会話が成立するようになる。過去の会話から普段住んでいるところ、会社まで交通ルートなどもわかるため、会社に最短でいつつくといった情報にも、個人的なルートを加味して回答するようになる。ただし、会話が続くと消費するトークンが雪だるま式に増えるため課題が残る。

Mark2.3 OpenAI APIで節約しながら永続的な会話を成り立たせる

消費するトークン量を節約するために過去の会話を要約する機能を実装。

Mark2.4 OpenAIを同時実行するマルチスレッド対応

OpenAIの１つしか呼べないような実装をしたたため、マルチスレッド対応に変更
これで、会話中に次の質問・依頼をしても対応するように改善

Makk2.5 OpenAI APIで永続的な会話を実現するための情報をカテゴリに分けて管理する

会話を要約する際に、カテゴリごとに分けて管理するように修正。

会話の中から、どのように要約するかを確認しプロンプトを微修正

Mark2.6 OpenAI APIを使ってやり取した会話を自ら保存し、必要に応じて引き出すようにし、効率化（≒無駄が少ない、＝節約した）を図る

要約したものの要約データが大きくなり、会話ごとに毎回読み込むとまたトークン消費につながるため、要約した情報をカテゴリごとにファイル保存し、必要に応じてOpenAIが該当するカテゴリファイルを読み込む方式に変更。それに合わせて、会話した内容から新たなものや変更になったものを、既存のカテゴリの毎の要約ファイルと比較し、整合のとれたカテゴリごとの要約ファイルを作成するように修正。

これで、例えば今日の予定は？と聞くと、要約ファイル（タスク）をOpenAIが自動的に読み込み、その情報をもとに会話ができるようになった。

Mark2.7 OpenAI　APIを使い、タイマー機能を実装

会話の中からあとで教えらしてほしい情報を抽出し、タイマー情報として記録する

本プログラムが起動した際に、別スレッドを起こし、タイマー用の機能を別スレッドで実行し、
上記で登録したタイマー情報を読み込み、該当する時間になった際に、Discordにメッセージを送信する機能を実装する。

Mark2.8 株価情報を取り扱えるように、お気に入り銘柄の管理と株価情報の取得、取得したデータの可視化（グラフ化）の機能を実装

AIとの会話を通し、お気に入り銘柄を登録・リスト化。
AIとは別のタスクとして、お気に入り銘柄の株価情報をバックグラウンドで取得、保存する機能を実装。
AIに対しては、株価情報を管理するツールを適用し、必要な株価情報をAIに提供できるようにした。
株価情報は保存されていればそれを利用し、なければネットから取得を行ってくる。
しかし、リアルタイムのデータは、売り物だということを知らなかった。現在は２営業前くらいの情報を無料枠の中で処理している。

Mark2.9 外部関数のマルチタスク化を実装、その他

OpenAIが扱える関数のマルチスレッド対応を実施。
その他、株価情報の取得機能とグラフ化の機能を統合。グラフを作る際にデータがなければデータを取得するように統合化。グラフタイトルに日本語が扱えるよう環境修正。
タスクリストデータのJSON化を行い、各タスクの期限、ステータスを管理できるように修正。
前回株価を確認した時間を管理するように変更。

Mark2.10 AIが扱いやすいようデータ保存形式を見直し

保存している記録情報をJSON形式に変更。JSON形式にしたことにより部分的なデータの抽出、置き換え、削除をAIから直接、精度を高く実現できるようにした。

Mark2.11 ResponseAPIに実装を変更

AssistantAPIを使っていたが、将来廃止されるとのことだったので、ResponseAPIに実装を変更。
正直使いにくくなった。元の実装はAIが考えているToolが要求されたら、その都度Toolを実行しAI に返却する実装をしていたが、それが出来なくなった。（正確にはわからないだけかも）。その対応が割と実装が大変だった。

追伸：かなりはまって２週間ほどデバッグにかかった（泣）。

Mark2.12 OpenAIのBatch対応

AIエージェントとの会話ログが大量になってきたので、整理するためにバックグラウンドで圧縮するためにBatch対応を実装。そのほか、全面的にソースのリファクタリングとエラー処理を強化し随分安定した。

Mark2.13 GoogleCalendar連携対応

AIエージェントからGoogleCalendarの操作を出来るようにした。会話の中から予定を確認したり、予定を書き込んだりできるように機能強化。