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

「.mdで作って」と頼んだのにGoogle Docs化する... Gemini Sparkと挑んだGoogle Drive API自動変換の壁

個人で管理している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」と指定していても、Google Drive側が気を利かせてGoogle Workspace形式（application/vnd.google-apps.document）に自動変換してしまう仕様になっている。

// リクエスト側（期待していた呼び出し）
drive:create_file({
  title: "20260913_[記録]_プロジェクト_v1.5.md",
  mime_type: "text/markdown",
  text_content: "# ライフ支援・AIエージェント開発プロジェクト..."
});

// 実際にGoogle Drive側から返ってきたレスポンス
{
  "title": "20260913_[記録]_プロジェクト_v1.5.md",
  "mimeType": "application/vnd.google-apps.document" // Google Docsに自動変換される
}

つまり、AIが指示を無視してDocsを作っていたのではなく、AIは指示通りにMarkdownとしてリクエストを投げていたものの、Google Drive側が「テキストデータ＝ドキュメント」と判断して勝手にDocs化していたのが真相だった。

3. 回避策：バイナリ形式でのアップロード

テキストとして本文をそのまま送信するとGoogle Driveの自動変換エンジンに捕捉されてしまうため、以下の手順で変換をバイパスすることにした。

  1. ローカル環境への書き出し: 一度サンドボックス側のローカル環境に、純粋な .md ファイルを書き出す。
  2. バイナリ（octet-stream）としてアップロード: text_content パラメータを使わず、ローカルファイルのパスを指定し、MIMEタイプを application/octet-stream（バイナリ扱い）としてAPIを呼び出す。
  3. 親フォルダへの移動: 作成完了後、フォルダ移動APIで目的のPARAフォルダへ配置する。

この手順を踏むことで、Google Drive側の自動変換をすり抜け、拡張子 .md、MIMEタイプ text/markdown のファイルとして正常に保存できるようになった。

4. ルールとスキルへの反映

この手順は今のチャットスレッドだけで解決しても意味がない。別のスレッドで動くエージェントが、また同じようにテキスト直接送信を行ってDocs化してしまうからだ。

そのため、以下の2箇所に技術仕様として明記した。

  • スキル指示書（append-to-second-brain、reading-memo）: 新規作成時は text_content を使わず、ローカルに生成した上で application/octet-stream でアップロードする手順を必須化。
  • 全体規約（タグ・命名ルール辞書.md）: AIエージェント共通の仕様として、バイナリアップロードによる自動変換回避ルールを追記。

5. なぜ .md で管理するのか

今回の件を通じて、改めてGoogleドキュメントとMarkdownの使い分けについて整理した。

項目 Markdown (.md) Googleドキュメント (.gdoc)
ローカルAI・ツール連携 ファイル実体があるため、Ollama、BGE-M3、Python、Obsidianから直接読み書き可能。 実体はWebポインタであり、API経由やエクスポートを挟まないと直接読めない。
ポータビリティ 特定サービスに依存せず、Git管理やZIPでのバックアップが容易。 Google Workspaceのエコシステム内に閉じる。
メタデータ管理 YAMLフロントマターやタグを埋め込みやすく、機械処理に向いている。 本文内に記載する形になり、プログラムからの自動抽出がやりにくい。
閲覧・編集のしやすさ DriveのWeb画面やスマホアプリではプレビュー表示になり、やや不便。 いつでも直感的にリッチな編集が可能。
他者共有・共同編集 記号混じりのテキストになるため、非エンジニア向けではない。 コメント機能や提案モードがあり、複数人でのレビューに適している。

二段階の運用方針

すべてをどちらか一方に統一するのではなく、用途で分けるのが一番無理がないという結論になった。

運用の切り分け

第一段階（個人ナレッジ、思考ログ、仕様書、第二の脳）: すべて .md で管理
日々の記録や技術メモ、ローカルAIとの連携用データは、機械可読性と検索性を最優先にしてMarkdownで一元管理する。

第二段階（他者共有、レビュー、提出用資料）: 必要に応じて .gdoc や HTMLスライドへ変換
他者と一緒に推敲する企画書や提出書類になった段階で、Googleドキュメント等へエクスポートする。

おわりに

AIが指示通りに動かないと感じたとき、プロンプトの書き方だけでなく、裏側で動いているプラットフォームやAPIの暗黙の仕様が原因になっているケースがある。

ログを見て何が起きているのかを一つずつ切り分け、プラットフォームの制約をバイパスする仕組みを作るという、インフラや自動化に近い試行錯誤だった。

ラベル:

コメント

コメントを投稿

このブログの人気の投稿

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

  この記事の結論（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.【病巣の解剖】完璧主義の皮をかぶった「完璧に見られたい欲」 水面上は「品質へのこだわり」に見えても、水面下の本体は「見栄と恐怖」 表面上の建前と水面下の本音 「完璧主義」という言葉は、どこか聞こえがいい。「クオリティを高く仕上げたい」「自分の役割や責任を全うしたい」という誠実なプロ意識のように見えるからだ。 しかし、水面下に潜っている巨大な氷山の本体を直視してみると、そこにあるのは品質へのこだわりではなく 「見栄」と「恐怖」 だった。 氷山の構造（建前と本音） 水面上（建前） : 高品質なものを出したい、自力でやり切りたい 水面下（本音） : 「できない奴と思われたくない」「弱みを見せられない」「不完全な自分には価値がない」 信念と呪いの表裏一体 私の中にはもともと、「先頭に立って開拓者であり続けたい」という強い信念がある。ゼロから何かを立ち上げたり、新しい仕組みを作ったりするとき、この信念は大きな推進力になる。 ところが、ひとたび「自分が得意ではない定型業務」や「正解が見えにくい抽象的な課題」に直面すると、この信念が裏返り、 「常に完璧であると見られなけ...
コメントを投稿
続きを読む