スキップしてメイン コンテンツに移動

【追記：2026年9月27日】Markdown統一の先でぶつかった「強制Google Docs変換」の壁と解決への試行錯誤

前回、「第二の脳（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）において、テキスト本文を直接渡すパラメータ（text_content）を使用すると、MIMEタイプに text/markdown を指定していようが何だろうが、Google Drive API側の挙動によって「テキスト本文が渡された＝編集可能なGoogle Docsへ変換する」という自動変換処理が強制的に発動してしまう仕様になっていたのだ。

つまり、エージェント側がどれほど強い意志で「Markdown形式にする」とプロンプトで自己暗示をかけていても、テキスト直接送信のAPIを叩いている限り、Drive側で強制的にDocsに変換されてしまう構造だったわけだ。

3. 解決策：バイナリアップロードによる2段階保存手順の確立

この強制Docs化インターセプターを回避するにはどうすればいいのか。答えは「Drive側にテキストファイルだと認識させず、バイナリストリームとして無加工で送り込む」ことだった。

試行錯誤の末に確立したワークフローは以下の2段階手順である。

  1. ローカルVM環境でのMarkdown一時ファイル生成
    エージェントの作業環境ローカル上に、完全なMarkdown構文で .md ファイルを一度書き出す。
  2. バイナリモードでのアップロード
    drive:create_file を呼び出す際、text_content は空文字にし、mime_type に application/octet-stream（汎用バイナリ）、base64_content にローカルファイルのパスを指定してアップロードする。これにより、Drive側のDocs自動変換機構を完全に素通りさせることができる。
  3. 親フォルダの移動・配置
    アップロード直後はマイドライブ直下に配置されるため、即座に drive:update_file を呼び出して目的のPARAフォルダ（01_Projects や 02_Areas）へ親IDを付け替える。

この手順を実行したところ、Google Drive上に自動変換されることなく、正真正銘のプレーンテキストな .md ファイル（MIMEタイプ: text/markdown または application/x-yaml）が綺麗に保存された。

# Google Drive強制Docs化を完全抑止するバイナリ保存の概念 def save_pure_markdown_to_drive(filename, content, target_folder_id): # 1. ローカルに純粋な.mdを出力 local_path = f"/tmp/{filename}" write_file(local_path, content) # 2. application/octet-streamでバイナリアップロード（Docs自動変換を回避） file_id = drive.create_file( title=filename, mime_type="application/octet-stream", base64_content=f"file://{local_path}", text_content="" ) # 3. 目的のPARAフォルダへ親を更新 drive.update_file(fileId=file_id, parentId=target_folder_id) return file_id

4. スキルへの恒久的な落とし込みと運用改善

手法が確立できたので、これを場当たり的な対話で終わらせず、エージェントのスキル定義へ完全に組み込んだ。

改修項目 旧来の仕様（append-to-second-brain） 刷新後の仕様（add-to-second-brain）
編集・作成ツール docs_agent（Google Docs専用編集）を併用 docs_agent全面禁止。バイナリアップロードによる.md保存のみ
ファイル形式 .gdoc と .md が混在しがちだった 純粋なMarkdown（.md）保存の完全徹底
版管理・更新手順 ドキュメント内への追記（ファイルは単一） 旧版DL ➔ 追記マージ ➔ バージョン採番（v1.5 ➔ v1.6）➔ 新規.md保存 ➔ 旧版は04_Archivesへ自動退避
ユーザー確認UI 自由文での聞き返し（回答の手間大） 新規スキル「inline-question-format」導入（ワンクリックコピー＆インライン回答）

特に、既存ファイルを更新する際に「旧ファイルを読み込み、追記セクションをマージしてバージョンを1つ進め、古いバージョンを自動的に 04_Archives フォルダへ隔離する」というライフサイクルを定義したことで、フォルダ内に同一タイトルのゴミが散らからず、常に最新版が先頭に保たれるようになった。

5. 今回の試行錯誤から得た教訓

プロンプトエンジニアリングやシステムプロンプトの調整だけでAIエージェントをコントロールしようとしても、裏で動いているAPIやクラウドサービスの内部仕様（今回で言えばGoogle Drive APIの自動変換トラップ）に阻まれることがある。

「なぜ指示通りのフォーマットにならないのか」をツールの入出力レベルまで潜って検証し、バイパス経路（バイナリアップロード）を見つけ出してスキルの手順として型化する。この「下位レイヤーの制約を上位レイヤーのプロトコルで飼いならす」感覚こそが、自律AIエージェントと実用的な作業環境を構築する上での一番の面白さであり、手応えだと感じている。

これでようやく、Google Driveとローカル（Obsidian / ローカルLLM）が一切の変換歪みなく、完全にプレーンなMarkdownで呼吸し合える環境が整った。第二の脳の自動化は、また一歩、堅牢になったと言えそうだ。

ラベル:

コメント

コメントを投稿

このブログの人気の投稿

悪気のない「カレーでいいよ」を防ぐ、脳内「外交官フィルター」の作り方

  この記事の結論（3行まとめ） 「〇〇でいいや」「〇〇でいいよ」という言葉は、言った側に悪気がなくても相手に「妥協・軽視」のニュアンスを伝えてしまい、無用な不快感を生むことがある。 これを 「〇〇でじゅうぶんだ」 と言い換えると、「他を探す必要がないほど満たされている」という肯定のメッセージに変わり、角が立たなくなる。 本音ではこだわりがない時ほど、自分の中に「外交官」を置いて言葉を1単語だけチューニングするのが、人間関係のダウンサイド（損失）を避ける合理的な知恵(になればいいな)である。
コメントを投稿
続きを読む

Zoff「RIRONE(集中メガネ)」はミソキネシアの対策にはならない 集中はできる

周りの人の動き、特に貧乏ゆすりがどうしても気になる。視界の端で何かが小刻みに揺れていると、そこに意識を持っていかれて、目の前の作業や本に戻ってこられなくなる。こういう特性を「ミソキネシア（Misokinesia）」と呼ぶらしい。 過去の記事 :   ミソキネシアについて その対策になればと思って、Zoffの集中メガネ「Zoff｜RIRONE」を買った。2024年12月に手に入れてから、約1年10か月使ってきたことになる。仕事、カフェでの読書、自宅での一人作業と、いろいろな場面でかけてきたので、 ミソキネシア当事者の目線 で正直な感想をまとめておく。 先に結論だけ書いておくと、 「集中するための道具としては良い。でもミソキネシアの対策にはならない」 だ。 フード(視界をカットする部分)がついた状態。 買うまでの話：視界を狭めるメガネを探していた もともと、視界を物理的に狭めるメガネが欲しかった。2024年の秋にはJINSやZoffの店舗を回ってみたけど、その時点では視界カット系のメガネはどこにも置いていなかった。仕方なく、カフェで紙をちぎってメガネに貼り付け、即席の目隠しを作ったりもした。首を固定しないと隙間から周りが見えてしまうし、正直だいぶガバかった。「もう自分で作ったほうが早いか」と、3Dモデリングでアタッチメントを自作することまで考えていたくらいだ。 そんなときに出てきたのがRIRONEだった。 Zoff｜RIRONEとは RIRONEは、教育系タレントの河野玄斗さんのブランド「RIRONE」とZoffのコラボで生まれたメガネで、2024年12月20日に発売された。周辺の余計な視覚情報をカットすることで、眼球の動きをコントロールする脳の部位「前頭眼野」の負荷を減らす、というのが売り文句だ。普段は普通のメガネとして使い、勉強やPC作業で集中したいときにフード（サイドの遮蔽パーツ）を付ける、という設計になっている。 手元の個体のテンプル刻印：ZN241028A_14E1 / 48□23-147 / French Plastic どの場面で使ったか 使ってきたのは主に次の3つのシチュエーションだ。 仕事：他の人と並んでPC作業をする カフェでの読書：知らない人の隣で本を読む 自宅での一人作...
コメントを投稿
続きを読む

「10%しかできてない！ならば仮病で報告を先延ばしにしないと！」という危険な思考癖とその対策

仕事において、期限のある重いタスクや目標設定シートの作成などを前にしたとき、どうしても着手が遅れたり、中間報告ができずに一人で抱え込んでしまったりすることがあった。 これまでの私は、そうやって仕事が進まなくなる原因を「自分は完璧主義だからだ」と片付けていた。最初からちゃんとしたクオリティのものを作ろうとするあまり、手が止まってしまうのだ、と。 だが、自分自身の行動パターンや内面を深く掘り下げて振り返ってみたとき、まったく別の正体が見えてきた。私が囚われていたのは、成果物の品質に対する純粋なこだわり（完璧主義）などではなかった。「相手から完璧な人間だと思われたい」「できない奴だと見られたくない」という、極めて自己保身的な 「完璧に見られたい欲」 だったのである。 本記事では、 「なぜ未完成を見せるのがこれほど怖いのか」 という部下側の内面構造と、 「報告を受ける上司側は本当は何を恐れているのか」 という視点の対比、そして私がスケジュール破綻の末にたどり着いた 「0%〜10%でさらけ出す仕事術の模索」 をまとめる。 1.【病巣の解剖】完璧主義の皮をかぶった「完璧に見られたい欲」 水面上は「品質へのこだわり」に見えても、水面下の本体は「見栄と恐怖」 表面上の建前と水面下の本音 「完璧主義」という言葉は、どこか聞こえがいい。「クオリティを高く仕上げたい」「自分の役割や責任を全うしたい」という誠実なプロ意識のように見えるからだ。 しかし、水面下に潜っている巨大な氷山の本体を直視してみると、そこにあるのは品質へのこだわりではなく 「見栄」と「恐怖」 だった。 氷山の構造（建前と本音） 水面上（建前） : 高品質なものを出したい、自力でやり切りたい 水面下（本音） : 「できない奴と思われたくない」「弱みを見せられない」「不完全な自分には価値がない」 信念と呪いの表裏一体 私の中にはもともと、「先頭に立って開拓者であり続けたい」という強い信念がある。ゼロから何かを立ち上げたり、新しい仕組みを作ったりするとき、この信念は大きな推進力になる。 ところが、ひとたび「自分が得意ではない定型業務」や「正解が見えにくい抽象的な課題」に直面すると、この信念が裏返り、 「常に完璧であると見られなけ...
コメントを投稿
続きを読む