AI との作業を、ログから翻訳レビューまでの運用に落とし込む#
AI をもっと上手く使うには、どうすればよいのだろうか。
この問い自体は大きい。 プロンプトの書き方、ツールの選び方、モデルの使い分け、作業の分解など、 考えることはいくらでもある。
ただ、自分のリポジトリに引き寄せて考えると、 すぐに試せることはかなり具体的だった。
このブログでは、AI とのやりとりをログとして保存し、
そのログをもとに日本語記事を書く流れを作り始めている。
さらに、日本語記事を gettext の .po に展開し、
機械翻訳したあと、AI と人間のレビューで英語として自然に整える、
という運用も見えてきている。
今回のセッションでは、 外部の AI 活用トピックをそのまま真似るのではなく、 このリポジトリにすぐ取り込める形へ落とし込むことを目標にした。
結果として、次の流れを整備することになった。
AI とのセッションをログとして保存する
ログから日本語記事を書く
人間が記事としてレビューする
gettext で翻訳対象を生成する
機械翻訳する
自然な英語になるように、AI と人間で修正する
やりたいことは派手ではない。 しかし、毎回の作業で迷わないようにするには、 こういう地味な運用の固定がかなり効く。
最初に考えたこと#
最初の関心は、 「AI 活用ノウハウをこのブログ運用にどう取り入れるか」 だった。
この時点で、リポジトリにはすでにいくつかの材料があった。
export_sessions.py では、
VS Code / Copilot Chat のセッションを Markdown として書き出せる。
docs/agents/ai-log-blog-writer.md には、
ログから記事を書くときのエージェント向け手順がある。
translate-po-ja-en.py では、
英語版 .po の機械翻訳を補助できる。
Sphinx 側には gettext のタスクがあり、
rye run doit gettext や rye run doit doc で翻訳とビルドの流れを回せる。
つまり、部品はすでにあった。
ただし、部品があることと、毎回安定して使えることは別である。
ログを読んで記事にする段階では、 AI の要約をそのまま受け取ると、 事実と推測が混ざるかもしれない。
翻訳では、 機械翻訳の結果が一見それらしく見えても、 日本語原文との意味ズレや、技術語の壊れ方を見逃すかもしれない。
そこで今回の中心は、 「AI に任せる範囲を広げる」ことではなく、 「AI の出力を人間が見直しやすくする型を作る」ことになった。
ログ記事化のチェックリストを作る#
まず追加されたのが、
docs/agents/log-extraction-checklist.md だった。
これは、AI ログから記事を書く前に見るチェックリストである。
主な観点は次のようなものだった。
何をしたかったかを 1 文で言えるか
なぜ調べたのかが書けるか
違和感や困りごとの起点があるか
試したことが時系列で整理されているか
わかったことと未解決点が分かれているか
次に試す行動が残っているか
この観点は、ログを記事にするときにかなり重要だと思う。
AI との会話ログは、そのままだと会話の順番に引っ張られる。 しかし、読者が読みたいのは、 会話の逐語的な再現ではない。
読者が知りたいのは、 なぜその調査を始めたのか、 どこで困ったのか、 何を試したのか、 どこまでわかって、 何がまだ残っているのかである。
ログには材料がある。 けれど、記事にするには、 その材料を読者向けの構造に並べ替える必要がある。
そのために、チェックリストには 「事実」「推測」「未確認」を分ける自己検証プロンプトも入れた。
これは、自分にとってかなり実用的な追加だった。 AI に記事素材を抽出させるだけでなく、 その抽出結果に対して、 もう一度 AI に批評させる流れを作れるからである。
AI の出力をそのまま信じるのではなく、 AI に一度点検させ、そのうえで人間が見る。
この順番にすると、 人間のレビューは少し楽になる。
翻訳レビューの入口を作る#
次に整備したのが、 翻訳まわりの運用だった。
新しく docs/agents/po-validation-guide.md と
docs/agents/translation-workflow.md が追加された。
translation-workflow.md は、
日本語記事を英語公開するまでの大まかな流れをまとめる文書である。
流れは次のようになる。
rye run doit gettext
rye run python translate-po-ja-en.py <対象.po>
rye run doit intl_validate
rye run doit doc
このうち、今回のポイントは intl_validate である。
dodo.py に新しいタスクを追加し、
英語 .po の状態を機械的に確認できるようにした。
確認するのは、主に次の3つである。
msgstrが空の未翻訳#, fuzzyが残っている翻訳msgidとmsgstrが同じままの項目
レポートは
docs/_build/_intl/validation-report.md に出る。
最初は単純な集計でよいと考えていたが、 セッションの途中で、優先度も見たいという話になった。
そこで、未翻訳、fuzzy、原文と同一の件数をもとに、
Priority score と Priority の列も出すようにした。
このあたりは、 「AI に直してもらう」前の地ならしである。
翻訳レビューでいちばん困るのは、 どこから見ればよいかわからないことである。 すべてを同じ重さで見ると、毎回の作業が重くなる。
まず機械的に危ない箇所を拾い、 優先度の高いファイルから見る。
そのうえで、po-validation-guide.md の観点に沿って、
意味一致、用語統一、英語としての自然さ、技術語の保持を確認する。
この流れなら、 機械翻訳を初稿として使いつつ、 公開前に人間が見るべき場所をかなり絞れる。
人間レビューを運用の中心に残す#
今回、地味に大事だったのは、 「人間によるレビュー」を消さなかったことだと思う。
AI の活用を考えると、 つい自動化を増やしたくなる。
ログ保存も、記事作成も、翻訳も、翻訳レビューも、 できるだけ AI に任せたくなる。
しかし、このブログでは日本語原稿が正である。 英語版は翻訳版であり、 意味の確認や変更理由は日本語で残す必要がある。
その前提では、 AI に任せる部分と、 人間が判断する部分を分けておくほうがよい。
たとえば、ログから記事にするとき、 AI は時系列の整理や論点抽出には強い。 一方で、 「自分は本当にその結論に納得しているか」 「この記事として公開してよい粒度か」 「未解決の違和感を消してしまっていないか」 は、人間が見るべきところである。
翻訳でも同じである。
AI は自然な英語への修正案を出せる。 しかし、 その修正が日本語原文の意図を保っているか、 技術的な固有名詞やコマンドを壊していないかは、 日本語原文と照らして確認する必要がある。
今回作った文書は、 AI を信用しないためのものではない。
むしろ、AI を継続的に使うために、 人間がレビューしやすい場所へ出力を持ってくるためのものだと思う。
実演したかった流れ#
セッションの最後では、 今回のやりとり自体を題材にして、 一連の流れを実演したいという話になった。
想定していた流れは次の通りである。
export_sessions.pyでログを保存する保存されたログから日本語記事を書く
人間が記事をレビューする
rye run doit gettextで翻訳対象を作るtranslate-po-ja-en.pyで機械翻訳するintl_validateで未翻訳や怪しい箇所を確認するpo-validation-guide.mdに沿って自然な英語へ修正するrye run doit docでビルド確認する
そして、後日同じことを思い出すために、 どのファイルを見ればよいかも整理した。
ログから記事化するなら、
docs/agents/ai-log-blog-writer.md と
docs/agents/log-extraction-checklist.md を見る。
翻訳の流れを思い出すなら、
docs/agents/translation-workflow.md を見る。
翻訳レビューの観点を思い出すなら、
docs/agents/po-validation-guide.md を見る。
コマンドやタスクの実体を確認するなら、
dodo.py と translate-po-ja-en.py を見る。
この時点で、 実演用の1ページランブックを作る案も出ていた。
ただ、ログを見る限り、
docs/agents/session-demo-runbook.md は最終的には作成されていない。
つまり、今回できたことは、 チェックリスト、翻訳レビューガイド、翻訳ワークフロー、検証タスクの整備までである。 実演用ランブックは、次に追加するとよさそうな残課題として残った。
わかったこと#
今回の学びは、 AI 活用は「便利なプロンプトを1つ覚える」だけでは続かない、 ということだった。
少なくとも、自分のブログ運用では、 次のような流れ全体を整えるほうが効きそうである。
入力を残す
AI に整理させる
AI の整理を検証する
人間が納得できる形へ直す
翻訳する
翻訳を機械的に点検する
最後に人間が意味を確認する
AI を使う場所は増えている。 しかし、人間が見る場所も同時に明確になっている。
これは、自動化が進んでいないというより、 自動化を運用に乗せるための足場ができてきた、 と考えるほうが近い。
特に、今回のように個人ブログであっても、 「日本語原文を正とする」 「英語版は翻訳として扱う」 「変更理由は日本語で残す」 というルールがあると、 AI の出力をそのまま公開するわけにはいかない。
だからこそ、 チェックリストや検証レポートが効いてくる。
毎回の作業で、 何を見ればよいか、 どこまで確認すればよいか、 どの順番で進めればよいかが決まっていれば、 AI を使うこと自体に余計な迷いが減る。
次にやること#
次にやるなら、 まずは今回の題材で、実際にこの流れを最後まで通したい。
この記事自体を日本語原稿として確定し、
gettext を更新し、
英語 .po を機械翻訳し、
intl_validate のレポートを確認し、
自然な英語への修正まで進める。
そのうえで、
後日見返すための
docs/agents/session-demo-runbook.md を追加するとよさそうである。
今はまだ、手順が複数のファイルに分かれている。 それ自体は悪くないが、 実演当日に見る入口としては、 1ページのランブックがあったほうが迷いにくい。
今回のセッションは、 AI 活用の抽象論ではなく、 自分のリポジトリの運用を少しだけ前に進める作業だった。
ログを残し、記事にし、レビューし、翻訳し、またレビューする。
この一連の流れを育てていけば、 AI との作業そのものが、 次の記事の材料になっていく。
記事情報
- 著者:
mtakagishi
- 公開日:
2026-05-31