ミジンコのミジンコ

自宅のWindows PC（RTX 3060 12GB）上で、OllamaやBGE-M3、ChromaDB、FastAPIを組み合わせた完全ローカルの自律AIエージェント基盤を作ろうと思い立ち、Gemini Sparkとの壁打ちを交えながら開発を進めていた。 AIとの協働開発はとにかく速い。こちらが「こういう機能が欲しい」と大まかな構想を投げれば、数往復のやり取りだけでアーキテクチャの提案からサーバー実装、フロントエンドのコードまで一気に仕立て上げてくれる。最初のうちは「これはとんでもない時代になった」と興奮していた。 だが、機能が増え、システムが形を帯びてくるにつれて、背筋に冷たいものが走るような強烈な違和感に襲われることになったのだ。 直面した違和感の正体 「いま、自分の画面の前で動いているこのシステムは、本当に正しく動いているのか？」――それが、作った本人であるはずの自分にすら、まったく分からなくなっていたのだ。 1. ログをAIに投げて初めて「正常動作」を知る情けなさ 何が起きているのかが分からない。画面上でチャットを送信し、バックエンドのコンソールにずらりと流れるログを眺めても、どのモジュールがどういう順序でデータを渡し、どの判定を通って出力に至ったのか、頭の中に「見取り図」が存在しないのだ。 動いているのか止まっているのかの判断すらつかず、困り果ててターミナルのログをそのままGemini Sparkに貼り付け、「これって動いているの？止まっているの？」と問いかける始末だった。 AIから「出力されているログは正常です。現在の仕様では、この判定を通ってバックグラウンドでインデックス処理が走っています」と冷静に解説されて初めて、「あ、これで合っているんだ……」と知る。作ったはずの開発者が、自分のプログラムの仕様と現在地をAIに教えてもらうという、本末転倒な事態に陥っていたのだ。 2. 「丸投げ」がもたらすブラックボックス化の恐怖 なぜこんなことになったのか。原因は極めて単純だった。AIとの会話の往復回数を減らし、初速を優先するあまり、設計の意思決定も、内部のデータフローの把握も、すべてAIに「丸投げ」してしまっていたからだ。 単機能の使い捨てスクリプトなら、それでも何とかなる。だが、F...

Google Drive上に構築している「第二の脳（Obsidian / PARA）」を、長大な肥大化から守るためにSLA構造（STATUS / LOG / ARCHIVE）へと全面移行した。だが、システム側の構造を美しく再編しただけでは現場は回らない。日々そこで記録を取るAIエージェントのスキルが旧来の思考ルーチンのまま動いていたことに気づき、突貫でスキルの再構築を行うことになった記録である。 1. 構造を変えたのに、現場の道具が旧型のままだった違和感 先日、第二の脳にある全主要プロジェクトのドキュメントを「SLAモデル」へと再編した。SLAモデルとは、ひとつの案件を以下の3つの役割に厳格に分離する設計思想だ。 STATUS（_00_STATUS.md） : 現在のアーキテクチャや進捗、最新の決定事項のみを保持する「上書き専用」のスリムなファイル。 LOG（_01_LOG.md） : 日々の作業経緯や会話メモ、検討プロセスを時系列で追記していく「追記専用」のファイル。 ARCHIVE（_02_LOG_ARCHIVE.md） : LOGが一定件数を超えた際に古い履歴を退避させる「移動専用」の保管庫。 この構造にしたことで、AIエージェントが過去の長大な歴史にコンテキストウィンドウを食いつぶされることなく、瞬時に「いまの状態」を把握できるようになった。めでたしめでたし、と胸をなでおろしていたのだが、ふと頭をよぎるものがあった。 「待てよ、普段使っている『++（第二の脳に追記）』や『-md（ドキュメント作成）』のスキルは、この新構造を認識しているのだろうか？」 気になってAIスキルの定義（SKILL.md）を開いて確認してみたところ、案の定だった。そこには旧来の「既存ドキュメントを検索し、末尾に追記してファイル名のバージョン（v1.5からv1.6）をインクリメントする」という、まさに単一巨大ファイル時代の処理フローがそのまま鎮座していたのだ。 ルール（格納庫の設計）だけを最新にしても、そこに出入りする道具（AIの行動ルーチン）が過去のやり方を引きずっていれば、遠からずSTATUSファイルにダラダラと作業ログが追記され、以前と同じ泥沼に逆戻りしてしまう。道具側にも新しいルールを叩き込まねばならない。 ...

前回、「第二の脳（about_me）の管理形式をGoogle DocsからMarkdown（.md）へ一本化する」という方針を決め、過去ドキュメント130件超の一括変換まで完了させた。  ※ 前回の記事 > .mdへ一本化した ローカルLLMやObsidianとの直接同期、Gitやスクリプトからのプレーンテキスト操作といった恩恵を実感し、これで一件落着したかに見えた。 だが、実際にAIエージェント（Gemini Spark）へ「この内容を第二の脳に追記して（++）」と指示し、実運用を開始した瞬間に、新たな技術的トラップが口を開けて待っていたのだ。 1. 発生した問題：指定しているのに「勝手にGoogle Docsになる」怪奇現象 エージェントに第二の脳のノート作成や追記を頼んだあと、Google Driveのフォルダを開いて確認したとき、思わず首を傾げてしまった。 作成されたファイルが、拡張子 .md のテキストファイルではなく、見慣れた青いアイコンの「Google Docs（.gdoc）」として鎮座していたのだ。 直面した違和感と困りごと プロンプトやスキル定義には「Markdown（.md）で保存すること」「Google Docs形式は禁止」と口を酸っぱくして明記してある。エージェント自身も「Markdownで保存しました」と報告してくる。それなのに、Google Driveの実体はGoogle Docsに化けてしまっている。これではローカルのObsidian保管庫や自作スクリプトから直接プレーンテキストとして読み書きできず、元の木阿弥になってしまうのだ。 一時的なバグなのかと思い何度か試行を繰り返してみたが、結果は同じだった。ドライブ内には削除候補の不要なGoogle Docsファイルが増えていく。これはプロンプトの書き方の問題ではなく、ツールの下位レイヤーに根本的な原因があると直感した。 2. 原因の調査：Google Drive APIの内部変換仕様 Gemini SparkがGoogle Driveへファイルを保存する際に呼び出しているツール仕様を詳しく追跡した結果、決定的な原因が判明した。 ファイル作成ツール（ drive:create_file ）において、テ...

個人で管理しているGoogleドライブ上の知識ベース（第二の脳）を、ローカルのObsidianや自作のローカルAIエージェントと連携させるため、保管するテキストファイルをすべてMarkdown（.md）で統一することにした。 ※追記 2026-09-27 > それでもgdocになる現象 普段使っているGemini Sparkに「メモを保存するときはGoogleドキュメント（.gdoc）ではなく、拡張子.mdのテキストファイルで作って」と指示したのだが、ここから少し予想外のトラブルシューティングに入ることになった。 起きた事象 ファイル名を「*.md」、MIMEタイプを「text/markdown」と指定しているにもかかわらず、生成されたファイルをドライブで見ると、なぜか毎回Googleドキュメント（.gdoc）に変換されてしまっていた。 1. ログを見て気になったこと Gemini Sparkの実行ログ（思考プロセスのタイムライン）を眺めていたところ、第二の脳への追記処理の中でGoogle Docsのアイコンが表示されていた。 スキルの指示がまだ反映されていないのか、それともAIにとってMarkdown形式で直接ドライブへ保存するのが難しい処理なのかが気になったので、直接聞いてみた。 質問: 「gdocからmdへの変換に苦労していただけ？ それとも、mdを書くこと自体に苦労していましたか？」 返ってきた答えはこうだった。 回答: 「mdを書くことでも、変換に手こずっていたわけでもありません。Google Drive API側の強制的な自動変換仕様をいかに回避するかに苦戦していました」 AIの指示追従の問題ではなく、受け側のAPI仕様の問題だった。 2. Google Drive APIの自動変換仕様 挙動を細かく確認したところ、原因はGoogle Drive API（drive:create_file）の内部仕様にあった。 テキスト本文（text_content）をAPIに直接渡すと、リクエスト側でMIMEタイプを「text/markdown」や「text/plain」と指定...

1. はじめに：自分専用の思考パートナーが欲しい 普段から Obsidian やGoogle Drive（PARAメソッド）を使って「第二の脳」として日々の記録や知識を蓄積しているが、次第に「蓄積したメモを検索するだけでなく、自分の思考の癖や過去の文脈を前提として受け答えしてくれる専属のAIエージェントが欲しい」と考えるようになった。 過去の自分のデータを探して、自分に合った回答を返してくれる。さながら伴侶。 商用クラウドAI（ChatGPTやGemini等）は優秀だが、今回は以下の理由から「完全ローカル環境」での運用を目指した。 日記や尖った創作プロットに対するアライメント（検閲）の回避 プライベートな思考ログを外部へ送信しないセキュリティ・プライバシーの確保 将来的なAPI従量課金コストの排除と固定費化 そこで、完全ローカル環境で動作する「自分専用AIエージェント」を自前PCに構築してみることにした。 結果として、構築作業そのものはAI支援ツールを活用して非常にスムーズに完了したが、いざ普段使っているPCで動かしてみると、 動作が想像以上に重く、日常作業に支障が出るレベルだった 。 今回はその構築プロセスと、実際に動かして分かった課題についての記録である。 2. システム構成と動作環境 外部の巨大なフレームワーク（LangChain等）を何重にも重ねると、プロンプトの肥大化や内部動作の不透明さを招きやすいため、Python標準と公式のOpenAI SDK互換機能を用いたシンプルな構成にした。 【システム構成】完全ローカル「自分専用AI」アーキテクチャ ① クライアント層（UI / 操作） Front-End 日常的な入力・対話インターフェース チャットUI シナリオエディタ CLI ▼...