AI が作った Google ドキュメント、毎回同じような修正をしていました

私の会社では、規程や方針、提案書のように人が読んで手を入れる文書を Google ドキュメントに置いています。この記事では、その Doc を AI（Claude Code）に作らせたり直させたりする自作スキル「gdoc-edit」について、1本の社内文書ができるまでを順に追ってお話しします。

結論を先に書きますと、夏から秋にかけての数か月で、Doc で困った体裁を9つ、道具の側に組み込みました。表の文字の大きさ、冒頭の日付と名前の位置、字下げなどです。いまは AI に Google ドキュメントを作らせても、同じ手直しを頼む回数はずいぶん減りました。

このスキルが育つ前は、AI が作った Doc を開くたびに、同じところを直していました。表の文字が本文より大きい、日付が左に寄っている、箇条書きが見出しより外に飛び出している、といった具合です。そのたびに「ここを直して」と頼めば直してはくれます。ただ、次の文書ではまた同じところが崩れていて、私は毎回同じことを言っていました。

下書きは、AI が Markdown で書きます

たとえば「在宅勤務の基本方針を、全社員向けの Doc にして」と頼むとします。AI はいきなり Google ドキュメントを作るのではなく、まず Markdown（記号で見出しや表を表す、ただのテキスト）で下書きを書きます。私が読むのもこの下書きで、中身のやりとりはここで済ませます。

下書きの先頭には、タイトル・サブタイトル・日付・作成者を書く欄があります。本文の見出しは # から始め、表は記号の縦線で書きます。下は、この記事の例に使ったサンプルの下書きです。

---
title: 基本方針（テレワーク）
subtitle: 全社員向け 2026年10月
date: 2026年10月12日
author: 株式会社サンプル 山田
---

# 1. 目的

在宅で働く日の連絡と記録の決まりを定めます。

# 2. 勤務の届け出

| 区分 | 届け出 | 期限 |
|---|---|---|
| 終日 | 申請フォーム | 前日まで |
| 半日 |  | 当日の朝 |

下書きを Markdown にしているのは、AI が速く書けて、前の版との違いも行単位で見比べられるからです。一方、Doc は社員がコメントを付けたり、表に色を塗ったりする場所です。中身は下書きで詰め、Doc にするのは最後の一度だけにしています。Doc を何度も作り直すと、そのたびにリンクを送り直すことになるので、それを避けたいという事情もあります。

AI は下書きを書き終えると、見出しと表の数を添えて報告してきます。私はその報告と下書きを読み、抜けている項目や言い回しを言葉で直してもらいます。この段階では Doc はまだどこにもありませんので、何度直しても社員の目に触れることはありません。下書きが固まってから、はじめて Doc にします。

Doc にする前に、検査が入ります

下書きができたら、Doc にする前に書式の検査を通します。最初のころは、表に空のセルが一つあるだけで、Doc を作る途中で失敗していました。その後、空のセルは道具が「—」で埋めて通すようにしましたが、今度は中身の抜けたまま Doc ができてしまいます。

また、表のセルの中に書いた太字の記号は、Doc では記号のまま残ります。どちらも、作り終えてから私が気づくまで分かりませんでした。

そこでいまは、Doc を作るコマンドが、実行の前に必ず検査を通るようにしています。上の例では、表の「半日」の行の届け出の欄が空いていたため、Doc を作る前に止まっています。欄を空けていた理由は私が先に答えていたので、AI はそのとおりに埋めてから Doc にしました。私は止まった理由と直し方を読んで、それでよいかだけを見ています。

止めるのは、中身の抜けた空のセルと、記号のまま残るセルの中の太字の二つだけです。一方、「／」で語を並べている、段落の途中で改行している、といった読みやすさの指摘は、表示はしますが止めません。止める範囲を広げすぎると毎回止まり、誰も検査の結果を読まなくなるからです。

Doc で崩れる書き方は、Doc を作る前に機械的に止めるようにしました。説明書に「空のセルは埋める」と書いても、AI は忘れる日があるので、ここは忘れても止まる仕組みにしています。

なお、検査は AI が自分で思い出して走らせるものではなく、Doc を作るコマンドの中に入れてあります。AI が検査を忘れて Doc を作ろうとしても、コマンドの側で止まります。ですから、AI の注意力に頼らずに済むわけです。

冒頭の4行と表は、AIがルールに沿って作成します

検査を通ると、下書きから Doc ができあがります。下の画像は、サンプルの下書きを実際に Google ドキュメントにして、PDF に書き出したものです。タイトルとサブタイトルは中央に、日付と会社名・名前は右に寄せて2行で並びます。社内で正式な文書を出すときの体裁で、下書きの内容からAIがルール通りに作成します。

表の文字は10ptで、見出しの行は灰色になります。表のすぐ下の段落には少し空きが入り、最後の行の「推奨」は青い太字になっています。どれも、一度は私が手直しを頼んだところです。困った時期と、AIがルール通りに処理していることを並べると次のようになります。

時期	困ったこと	いま道具がすること
夏ごろ	表の文字が大きい	表は全セル10ptで作る
9月の初め	貼り付けた後に記号が残る	境界線と残った記号を片付ける
9月の半ば	冒頭の4行を毎回手で整える	先頭の4欄から冒頭の4行を組む
9月の終わり	空のセルや表の中の太字に後で気づく	作る前の検査で止める
9月の終わり	箇条書きが外に出る	字下げを1か所にそろえる
10月の初め	表の下の文字が詰まる	表の直下に10ptの空き
10月の初め	「推奨」が埋もれる	青い太字にする
10月の初め	話の区切りが分からない	空行2つで空の段落を置く
10月の初め	箇条書きの中の太字が効かない	箇条書きの中も太字にする

これは、行きつけの床屋に似ていると思います。最初に一度「横は短めで」と伝えておけば、次からは「いつもので」で同じように仕上げてくれます。一度言った体裁は、道具が「いつもの」として覚えるようにしました。こうして覚えた「いつもの」は、Doc を作るたびにAIが黙って当ててくれます。

Google ドキュメントへの指摘は、その場の手直しで終わらせません

体裁の指摘をしたとき、AI がまずするのは、目の前の Doc を直すことです。ただ、それだけで終わると、次の文書でまた同じところが崩れます。そこで、同じ指摘が二度目に出たら、その直し方をルールに入れるようにしています。字下げも、最初は AI がその場で書いた短いスクリプトで直していました。

字下げは、その典型でした。Doc にしたあと、箇条書きの位置が見出しより外に出ている、と私が二度続けて指摘しました。そこで、字下げをそろえるコマンドを一つ作りました。見出し・本文・表は左端に、箇条書きは決まった1か所に、入れ子は1段ごとに同じ幅でずらします。いまは Doc を作ったあとに、このコマンドを必ず流しています。

同じ指摘が二度出たら、それはルールに足りない部分の印だと思っています。ただし、正直に書きますと、その場の書き換えはまだ0になっていません。会議の資料のように、文書ごとに体裁の決まりが違うものでは、今も AI がその場で直しています。決まりが一つに定まらないものまで既定にすると、かえって他の文書が崩れるからです。

そのため、既定にするかどうかは、全部の文書で同じでよいかどうかで決めています。言えるものはルールに加えて、説明書の決まりにも書き足します。そう言えないものは、その文書の手直しとして残します。こうして少しずつ「いつもの」が増え、最初に挙げた9つになりました。

出したあとの小さな直しは、言葉で頼みます

Doc を出したあとにも、直しは出てきます。一文足したい、日付を変えたい、といった小さな直しです。こちらは Doc を作り直すわけにはいきません。社員が付けたコメントや、あとから貼った画像が消えてしまうからです。そこで、小さな直しは、狙った箇所だけを変える道で当てています。

私は「届け出の段落の後ろに、忘れた日の扱いを一文足して」と言葉で頼みます。AI も、足す場所と足す文を言葉で示してきます。裏では、AI がその直しを機械向けの作業ファイルに書き、足す場所が文書の中に1か所だけあるか、コメントの付いた文に重ならないかを数えています。私が目にするのは、その結果を言葉にした報告だけです。

提案は言葉で受け取り、場所の確かめは機械に任せています。足す場所の文が2か所に見つかったら、そのまま当てずに、もっと長い文で場所を言い直してから当てます。また、当てる直前には本文を控えに取り、終わったら表やコメントの数が前と変わっていないかを見ます。Google ドキュメントの版の履歴には変えた理由までは残らないので、節目の版は、理由を一言添えて控えています。

また、直す文にコメントが付いている場合、AI はその文を置き換えずに、後ろに一文足す形を提案してきます。コメントは文に貼り付いているので、文を置き換えるとコメントが行き場を失うからです。社員が残した指摘を消さないための決まりで、これも説明書に書いてあります。こうした直し方の決まりも、体裁と同じく、一度困ったところを説明書やルールに足してきたものです。

自分の環境で動かす

スキルは、AI が読む説明書（.claude/skills/gdoc-edit/SKILL.md）と、Google Docs API を使う Python のルールでできています。ルールは、Doc を読み書きする本体、作る前の書式の検査、字下げの整形の三つです。

体裁は道具に、どこで止まって何を確かめるかは説明書に分けています。説明書の要点を、社内の決まりを外して一般化すると次のようになります。

---
name: gdoc-edit
description: Google ドキュメントを下書きから作り、狙った箇所だけ直す。「この内容を Doc にして」「この Doc の◯◯を直して」と言われたら使う。
---
# 作る
1. 下書きを Markdown で書く（先頭に title / subtitle / date / author）
2. 書式の検査を通す（空のセル・セルの中の太字は止まる）
3. Doc にする（表と冒頭の体裁は道具が組む）→ 字下げをそろえる

# 直す
- 小さな直し: 直し方を言葉で示す → 作業ファイルで場所と件数を点検 → 承認を待つ → 控えを取って当てる
- 大きな直し: 下書きを直して同じ Doc を組み直す（画像とコメントが無い文書だけ）

# 体裁の指摘を受けたら
- まず目の前の Doc を直す
- 同じ指摘が二度出たら、ルールの既定に入れる候補として報告する

原文は社内のパスや決まりを含みますので、要点だけを載せました。Python の道具は配布していません。そのため、同じ形のルールは Docs API で用意する必要があります。中心になるのは、複数の変更を一度に送る batchUpdate です。

前提は、Claude Code、Python 3.9 以上と Google API のクライアントライブラリです。加えて、Google Cloud で Docs API と Drive API を有効にし、OAuth の認証ファイルを取ります（無料枠で足ります）。初回だけブラウザでの承認が要り、以後は保存したトークンで動きます。

起動の言葉は「この内容を、全社員向けの Doc にして」です。体裁の既定は会社ごとに違いますので、最初は空のままで構いません。まずは1本作ってみて、気になった体裁を一つずつ既定にしていくのがおすすめです。

まとめ

• 中身は下書きで詰め、Doc は最後に作る
• Doc を壊す書き方は、作る前に止める
• 一度言った体裁は、ルールの既定にする
• 同じ指摘が二度出たら、ルールに入れる
• 小さな直しは、言葉で頼んで機械が確かめる