ただ、正直に言うと、この数字は速さの証拠にはなっても、品質の証拠にはなりません。行数もコミット数も開発時間も、正しく動いているかどうかまでは教えてくれないからです。それでも、Flutter、React、Python、PostgreSQL、AWS、PHPとばらばらの技術を使う5つの個人開発を、一人で公開やテスト配布まで進められた速度は、1年前なら考えにくいものでした。

バイブコーディングと呼ばれる進め方で個人開発を続けるうちに、時間の使い方が変わりました。コードを一行ずつ読む時間が減り、代わりにDB全体、実際の画面、テストの中身、バックアップ、反映後の状態を見るようになったんです。AIに実装を任せても、人の仕事が消えたわけではありません。確認する単位が、コードからシステム全体へ移っただけでした。

バイブコーディングという言葉と、私の使い方のずれ

「バイブコーディング」は、Andrej Karpathyが2025年2月の投稿で広めた言葉です。AIが生成した差分をほとんど読まず、動きを見ながら会話で直していく方法で、Karpathy自身は、使い捨ての週末プロジェクトには悪くない、という温度で紹介していました。それが2025年には、CollinsのWord of the Yearに選ばれるところまで広がっています。

で、私の進め方はこの定義と少しずれているんです。コードをほとんど読まずに進めること自体はよくあります。ただ、対象は使い捨てではなく、継続して運用するサービスです。バックアップ、Git、テスト、本番確認までAIに頼みますが、その結果は最後に自分で確かめます。Karpathyがあとから区別した「agentic engineering」のほうに近い進め方だと思います。

ここで「コードを読まないほうが良い」という話に聞こえたなら、それは違います。読まないこと自体は目的ではなく、限られた時間のなかで、どの確認が品質にいちばん効くかを選んだ結果です。認証、権限、課金、削除のようにコードレベルの確認が欠かせない領域は別で、静的解析や第三者のレビューもあわせて使います。

5つの個人開発と、それぞれの到達点

2026年7月12日に、各リポジトリのGit履歴と公開状態を調べました。冒頭の数字も、このとき確かめたものです。

使っている技術も公開の形もばらばらです。それでも、進め方はどれも同じでした。目的を言葉にして、AIにリポジトリを読ませて実装とテストを進めてもらい、最後に公開状態を自分で確かめる、という流れです。

kessan-trackerの約22時間や、Chore Pointsの37コミットが示すのは、AIが広い範囲を短時間で変更できるという事実です。これ、裏を返すと、間違った前提も同じ速さで広がるということなんです。変更が大きいほど、確かめる範囲も一緒に広げないと釣り合いません。

1年前の私は、差分を読んで直していた

1年前の私は、Claudeに関数や画面のコードを書いてもらい、変更箇所を読んで、気になるところは手で直していました。AIはあくまで、便利な実装補助でした。その頃といまを並べると、変わったのは頼む範囲だけではありません。

WordPressテーマのJournalを作ったときも、要件と優先順位は自分で決め、実装のたたき台はAIに作らせ、本番へ出すかどうかは自分で判断していました。いまはそこからさらに進んで、テスト、バックアップ、デプロイ、公開後の確認までAIに任せています。

それでも、目的を決めて、作業を分けて、危ない場所を予測して、結果を確かめるという流れ自体は、1年前から変わっていません。変わったのは、一人でも複数の実行役に仕事を渡せるようになったことでした。

いま見ているのは、DBと画面とテストと戻し方

AIが出したものを、そのまま信じて公開しているわけではありません。私が確かめているのは、利用者から見える結果が、システム全体の動きとつじつまが合っているかどうかです。具体的にはこの4つを見ています。

• DB全体：件数、合計、重複、欠損、外れ値、更新前後の差
• 実際の画面：状態遷移、戻る、削除、再実行、通信失敗
• テスト内容：境界値、異常系、期待結果が目的に沿っているか
• リリース手順：バックアップ、Git差分、戻し方、反映後の確認

並べてみると、どれもコードの中身ではなく、動いた結果を確かめる項目です。テストコード自体はAIに書いてもらえますが、それだけでは確認が終わりません。AIは自分が実装したときの前提に沿ってテストを書くので、実装とテストが同じ思い込みを引きずることがあるからです。どこが壊れやすいか、利用者から見てどんな結果になるべきかは、人が決めて確かめるしかありません。

ついでに言うと、DBと画面を見るだけで、コードレベルの安全性まで確認できるとも思っていません。認証、権限、外部入力、依存関係については、静的解析やセキュリティテスト、必要に応じて経験者によるコードの確認を重ねます。

Web APIの話なのに、SQLiteが入ってきた

趣味で続けてきたプログラミング経験がいちばん役立ったのは、実はコードを書く場面ではありませんでした。AIの提案に違和感を持った場面です。

あるとき、Web APIを作る話をしていたのに、AIがローカルにSQLiteを入れ始めました。SQLiteが悪いという話ではないんです。複数の利用者や環境から使うという要件に対して、データの保存先と正本の決め方が合っていませんでした。

時刻でも似たことが起きています。UnixタイムスタンプとJSTに変換済みの日時が混ざったり、DB側とフロント側が別々に現在時刻を取って数秒の差が出たりしていました。一つひとつの処理は動いているのに、期限判定や並び順、日付の境界で組み合わせると矛盾が出ます。

あとから見れば、どちらも正本を複数作ってしまった失敗です。データでも時刻でも判断でも、正本が複数あると、処理同士のつじつまはどこかで合わなくなります。AIはその場では正しいコードをすばやく書いてくれます。でも、コード同士をつないだときに出る矛盾は、目的と全体像を踏まえて見ないと見つかりませんでした。

経験の使いどころは、書く場面から警戒する場面へ

時間、権限、同期、削除、外部API、課金。複数の状態が絡む処理を見ると、「ここは複雑になりそうだ」と身構えます。この勘の出どころははっきりしていて、過去に自分で似た失敗をしてきた経験です。

2026年6月にAnthropicが公表した約40万件のClaude Codeセッション分析にも、近い話が出てきます。典型的なセッションでは、人が計画上の判断を多く行い、Claudeが実行上の判断を多く担っていたそうです。対象業務に詳しい利用者ほど、結果を検証できる形で成功しやすい傾向も報告されていました。

もっとも、この調査は実社会で採用された成果物まで測ったものではなく、セッションの分類にもモデルを使っています。その分は割り引いて読む必要があります。それでも、コードの構文を知っていること以上に対象業務への理解が効くという点は、私の実感とよく重なりました。

だから、プログラミング経験がいらなくなったとは思っていません。ただ、使いどころは変わりました。コードを書くためではなく、前提の違いに気づくため、どこを重点的にテストするかを選ぶために使う場面が増えています。

間違いも速いから、戻し方を先に決めておく

AIが間違えるのは、未知の難問とは限りません。時刻の扱い、開発環境と本番環境の取り違え、削除範囲、ビルド対象、昇順と降順といった、人間も間違えやすいところで同じように間違えます。違うのは、その間違いを短時間で広い範囲へ反映できてしまうことです。

なので、削除を伴う作業では先にDBのバックアップを取り、コードと設定はGitに残します。ただ、Gitで戻せるのは管理対象のファイルが中心で、DBのデータや未追跡の素材までは守ってくれません。復旧の手段は分けて用意しています。

バックアップもGit操作も、作業そのものはAIに頼めます。人が決めるのは、「この操作の前に何を保存するか」と「どの確認結果が出るまで完了にしないか」の2つです。

後回しだった異常系に、時間を回せるようになった

以前の一人開発では、ひとまず動くところまで作るだけで時間を使い切り、異常系のテストを後回しにすることがありました。いまは実装をAIに任せた分、浮いた時間をDBの確認、複雑な画面操作、テスト観点の追加に回せています。

AIを使ってテストを省いたのではなく、順序が逆なんです。実装を任せられる相手が増えたから、一人でもテストに余力を割けるようになりました。テストコードの本数よりも、「二人が同時に操作したら」「通信中に戻ったら」「削除後に同期したら」と考える時間が増えたことのほうが、私には大きな変化でした。

作り始めるハードルと、本番へ出すハードルは別

技術的な実現方法を知らなくても、AIに選択肢や失敗例を説明させて、テストを作らせることはできます。むしろ業務をよく知る人のほうが、現場固有の例外に早く気づけることもあるくらいです。

「この操作のあとに戻ったらどうなる」「二人が同時に押したらどうなる」「間違った値をどう直す」。こう考える力は、エンジニアだけのものではありません。非エンジニアでも、自分がよく知る業務の道具なら形にしやすくなりました。

ただし、始めやすくなったことと、本番で使える品質が手に入ることは別です。最初は、失敗しても影響の小さい道具から選ぶのが良いと思います。個人情報、課金、削除、外部公開が絡むなら、必要に応じて経験者や第三者の確認も入れてください。

約22時間の先に残っていた、検収という仕事

kessan-trackerを約22時間で本番構成まで進められたのは、調査と実装をAIが引き受けてくれたからです。ただ、その22時間が終わった時点では、XBRLタグが正しいか、DBに欠けがないか、ランキングが逆順になっていないか、公開後も更新し続けられるかは、まだ分かっていませんでした。そこから先が、私の仕事です。

いまの実感を言葉にすると、一人で何でもできるようになったのではありません。一人でも実装を分担し、結果を確かめることに集中できる開発チームを持てるようになった、ということです。

1年前の私は、差分を読むことでその確認をしていました。いまの判断材料は、コードを読んだ行数ではなく、目的、正本、異常系、復旧、完了条件をどこまで確かめたかです。バイブコーディングで個人開発がどれだけ速くなっても、品質の判断は結局ここへ戻ってくると感じています。

このブログのWordPressも、同じやり方で回しています。下書き、画像設定、バックアップ、反映後の確認までAIに任せて、最後に結果をもう一度取得し、自分が頼んだとおりの状態になっているかを確かめています。

devXserverのWordPress運営をAIで効率化｜任せた作業と人が決めたことXserverのWordPress運営にAIとWP-CLIを使い、15記事のアイキャッチ差し替えや下書き…→

用語と調査の参照先

• Andrej Karpathy：vibe codingを紹介した投稿
• Andrej Karpathy：agentic engineeringについての投稿
• Collins：Word of the Year 2025
• Anthropic：Agentic coding and persistent returns to expertise

で、例外が出るたびに、指示ファイルへ注意事項を書き足すことになります。出力の形式がずれたら、また追記です。経理をAIで自動化したはずなのに、気づけば、AIに読ませる手順書の保守と、同じ判定を何度も確かめる作業のほうが、新しい定型業務になっていました。

いまは、内容が固まった定型処理をAIにPythonでコード化してもらい、スケジューラから毎回同じ処理を動かしています。AIに任せるのは、コード作成から実行の補助、結果の整理、例外の調査まで。要件を決めて、最後に承認するのは人です。

AI向けの指示書に書くこと、書かないこと

AGENTS.mdやCLAUDE.mdのような、AIが作業前に読む指示ファイルは、いまも使っています。ただ、起きたことを何でも書き足しても、結果は安定しませんでした。注意事項をいくら増やしても、同じ結果が返ってくる保証にはならないんです。

指示書で伝えるのは、対象業務、参照する正本、実行コマンド、書き込んではいけない範囲、承認が必要な操作、異常時の停止条件です。要するに、どこで動かし、どこから先を人が判断するのかという線引きだけを書きます。

一方で、日付の正規化や金額計算、登録番号の形式検査、CSVの突合、必須項目の欠落判定は、もう答えが決まっています。こうした処理を自然言語の指示から毎回読み取らせると、モデルや会話が変わるたびに、出力を確かめ直すことになります。毎回やっていたのは、まさにこの確認でした。

固定できる処理をコードへ移すと、コード、入力、参照データ、実行環境が同じである限り、同じ判定が返ってきます。要件が変わったときも、Gitの差分を追えば何をどう変えたのか分かります。文章に書いた指示との違いは、ここにあります。

では、そのPythonは誰が書くのか

定型処理をコードへ移すと言うと、経理の側がPythonを覚える話に聞こえるかもしれません。実際には、コードを書くところからAIの担当です。人が用意するのは、業務要件と正常例、異常例、それから期待する出力です。

1. 現在の手順と判定基準を文章で整理する
2. 正常データと異常データをAIへ渡す
3. Pythonの初稿と検証方法を作らせる
4. 過去データに対して実行し、期待結果と突合する
5. 要件どおりになった処理を次回も再利用する

この流れを一度とおった処理は、翌月も同じコードで動かすだけです。

とはいえ、全部がきれいに自動になったわけではありません。現在の実装には、承認済みの科目対応を処理対象ごとに追加していく仕組みが残っています。設定ファイルへの切り出しも自動テストの整備もこれからで、完全な無人運転ではないのが実際のところです。

もちろん、AIが書いたコードにも誤りは入ります。それでも、入力と出力を保存して同じ条件でやり直せるので、会話の中の解釈だけに頼っていたころより、原因を絞りやすくなりました。

経理のAI自動化を5つの役割に分ける

この分け方は、公開されている設計指針とも合っています。2026年7月17日に確認したOpenAIのエージェント実践ガイドは、あらかじめ決めたルールだけでは扱いきれない業務を、エージェントの候補としています。Anthropicも、明確な手順で処理できる仕事にはワークフローを、手順数を予測しにくい開かれた問題にはエージェントを、というように使い分けています。

経理の話に引き付けると、答えの決まった計算をAIに考えさせ続ける必要はない、ということです。Pythonに正常系を処理させ、まだルールのない例外で止めます。AIの柔軟な調査を使うのは、そこからです。

役割は5つに分かれました。指示書、要件文書、Python、AI、人です。それぞれに、置くものと置かないものを決めています。

見てのとおり、AIを処理から外したわけではありません。プログラムを作り、必要に応じて実行し、結果を読んで修正案を出すところまで任せています。任せたうえで、内容が固まったロジックはその場の会話に置かず、あとから同じ条件で動かせるコードとして残しています。

前払費用の月次処理での分け方

実際の経理業務では、前払費用の月次処理をこの形に分けました。Pythonが対象取引を抽出して、証憑を取得します。利用期間が確定した明細は、日割り計算、摘要の正規化、月別集計までそのまま進みます。

• Python：対象抽出、期間計算、更新データ作成、集計、更新後の件数と合計の検証
• AI：文字情報を持たない証憑のOCR、過去仕訳と証憑内容から科目候補を整理
• 人：利用期間や科目候補を確認し、本番反映を承認

効いているのは、検証までPython側に入っている点です。更新時に残すべき項目、更新順によって起きる一時的な超過エラー、書き込み後に確かめる合計——以前ならAI向けの注意書きにしていた内容を、処理と検証そのものに組み込みました。

申請チェックも考え方は同じです。テキストを取得できる証憑は、金額、日付、登録番号、税区分をPythonで判定します。画像やスキャンの証憑だけをAI-OCRに送り、按分や規程上の特例は人が判断します。

新規取引先チェックと経費精算のレシート照合を運用したあとで、何度も繰り返す正常系をコードへ移しました。

ルールのない例外だけをAIに戻す

プログラムは、あらかじめ決めた条件には強い一方で、ルールにない事情まで勝手に決めさせるわけにはいきません。実際、前払費用の処理でも、こういうケースが出てきます。

• 証憑に利用期間が書かれていない
• 複数明細へ按分されている
• 過去データと現行システムで金額がずれる
• 税務上の特例が疑われる

こうしたケースは「要確認」で止めます。止めたあとが、AIの出番です。関連資料と過去の処理を調べてもらい、確認できた事実、差異の原因候補、選択肢、推奨する対応、不足している情報を整理してもらいます。人はその根拠を読んで、どの対応を採るかを決めます。

流れとしては、こうです。

1. Pythonが正常系を処理し、例外一覧を出す
2. AIが例外の根拠と対応案を調べる
3. 人が方針を決める
4. 一度きりなら例外記録として残す
5. 繰り返すならテストケースに加え、コードへ反映する

例外が出るたびに指示書を長くしていた冒頭のやり方とは、ちょうど逆向きです。繰り返し現れる条件だけをコードへ戻すので、次回から人が確かめる対象が減っていきます。

二重実行のその後

この分業で減ったのは、実行時間だけではありませんでした。同じルールを毎回説明する、全件の出力を読み直す、同じ例外をもう一度調べる、複数の指示書に同じ変更を書く、といった作業がまとめて減りました。

• 定型ロジックの変更先を共通のPython処理へ集約できる
• AIと人が見る対象を全件から例外一覧へ絞れる
• 繰り返す例外をテストとコードへ移せる
• モデルや実行環境が変わっても、入口の指示書を大きく直さずに済む

冒頭の二重実行も、この形で解消しています。実際の処理をスクリプトへ集約し、AI向けの入口は「何を読み、何を実行するか」だけに絞りました。正本と起動経路が1つになったので、同じ判定を三重に管理せずに済んでいます。

コードにしたあとの安全網

コードにしたから安心、という話でもないんです。要件そのものが間違っていれば、コードは同じ間違いを高速で繰り返します。正直に書くと、現時点では体系的な自動テストがなく、dry-run、1件だけの実行、実データを再取得して照合する方法に頼っている部分もあります。

• 既定はdry-runにし、書き込みは明示的に指定したときだけ実行する
• 対象を1件に絞って確認してから全件へ広げる
• 更新前データを保存し、更新後に件数、金額、合計を再取得する
• 未定義パターンは処理せず、不一致で止める

足りない部分も、まだ残っています。一部の処理では、異常を検知したときの自動停止も、失敗後の復元も、実装できていません。自動テストと停止処理は、これから増やしていくところです。それでも、同じ条件で誤りを再現して差分を確かめられるようになったこと自体は、前進でした。

最初の1業務を移すときの手順

やったことは次の6つに収まります。

1. 業務を定型処理、例外調査、最終判断に分ける
2. 頻度が高く、入力と期待出力が明確な処理を1つ選ぶ
3. 正常例と異常例をAIへ渡し、Pythonと検証方法を作らせる
4. 読み取り専用またはdry-runで過去データと突合する
5. 指示書には正本、実行コマンド、禁止事項、承認条件、停止条件だけを置く
6. 例外はAIに調査させ、人が決め、繰り返すものはコードへ反映する

同じチェックが2つの経路から動いた原因は、AIが指示を守れなかったことだけではありませんでした。固まった処理の正本と起動経路を、文章の中にいくつも作っていたことにもありました。

例外のたびに指示ファイルへ注意事項を書き足していたあの作業は、いまは、繰り返す例外をテストとコードへ移す作業に置き換わっています。手順書の保守が新しい定型業務になる状態には、戻っていません。

定型処理はAIに毎回考えさせず、AIにコード化してもらう。実行と結果の整理も任せ、コードで扱えない例外だけを調べてもらう。

承認と責任をどこに置くかは、経理AIの内部統制について書いた記事で詳しく紹介しています。

経理経理AIの内部統制はどう設計する？作業と責任、証跡の分け方経理業務をAIに任せても、承認する人の責任まで移るわけではありません。新規取引先と経費精算の実例から、入…→

設計判断の参考にした資料

• OpenAI：A practical guide to building agents
• Anthropic：Building Effective AI Agents

きっかけは、Fable 5に出した1つの指示でした。約30分動いて、私の環境では5時間枠をほぼ使い切ったんです。一方のSol Ultraは、かなり仕事を渡したあとで「もう少し枠がほしい」と感じる程度でした。頼んだ範囲を、こちらが確認できる形で終えてくれる場面も目立ちました。

ただ、同じ課題を何度も流して測ったベンチマークではありません。普段の個人開発で、指示の守り方、手戻りの多さ、利用枠の減り方を見て感じた比較です。ここから両モデルの客観的な性能順位までは決められません。

Sol UltraとFable 5に渡した、日常の小さな仕事

私がAIに頼んでいるのは、モデルの限界を試すような難問ではありません。リポジトリの整理やドキュメントの更新、小さな機能追加、テスト、公開後の確認といった、毎日のように繰り返す仕事が中心です。

2026年7月17日時点の公式情報では、Claude Fable 5は、Anthropicが長時間の複雑な知識労働やコーディング向けに出している上位モデルです。GPT-5.6 SolはOpenAIのフラッグシップで、高性能設定のUltraでは標準で4つのエージェントが並列に動きます。

想定されている土俵が違う以上、私の小さなタスクだけで優劣は言えません。知りたかったのはもっと手前のことで、必要な前提を渡したあと、どちらなら普段の仕事を任せ続けやすいか、という一点でした。

同じ種類の仕事を渡して見えた差

利用枠の行は、APIのトークン単価をそろえて測った数字ではありません。それぞれの定額プランを普段どおり使って、画面に表示される利用可能枠の減り方を見比べた体感です。

性能差の行にあるとおり、私の仕事の範囲では、賢さの明確な差を確認できていません。差が出たのは、指示の守り方と利用枠の減り方でした。

30分動いた1つの指示で、次の依頼が出せなくなった

Fable 5が仕事をこなせなかった、という話ではないんです。結果はきちんと出ました。ただ、指定した範囲を超えたり、条件からずれたりして、追加の修正をお願いする場面がありました。

正直、上位モデルなら説明が少なくても意図を補ってくれるだろうと期待していました。実際には、何が正本で、目的と完了条件はどこにあって、何をしてはいけないか、丁寧に渡す必要がありました。この点はSolでも変わりません。

そのうえで、1つの指示に約30分動いた結果、5時間枠がほぼ消えました。Claudeの公式ヘルプにも、有料利用には5時間単位のセッション上限があり、上限に達するとリセット時刻まで待つよう表示される、とあります。

長時間、自律的に動き続けられるのはFable 5の強みのはずです。ただ、日中に小さな依頼を何度も渡す私の使い方では、その強みより、1回の作業で次の依頼を出せなくなることのほうが響きました。

Sol Ultraで減った、軌道修正の回数

Sol Ultraで印象に残ったのは、難問を一発で解いた、みたいな派手な場面ではありません。変更していい範囲と完了条件を渡すと、その中で調査、変更、テストまで進めて、こちらが確認できる状態で終えてくれることが多かったんです。

途中で「そこまでは触らなくていい」と止める回数が少なければ、成果物を確認する手間も減ります。私にとっての使いやすさは、賢そうな回答が返ってくることより、終わった仕事と残った仕事を見分けやすいことでした。

もちろん、Ultraなら曖昧に頼んでも意図どおりに仕上げてくれる、というわけではありません。誤った前提を渡せば、その前提のまま丁寧に進んでしまいます。標準で4エージェントが動くぶん、軽い作業に常用すれば利用量も増えます。

上位モデルでも、渡す前提は減らなかった

どちらを使うにしても、結局、毎回これだけは渡していました。

• 何を正本として読むか
• 今回の目的と完了条件
• 変更してよい範囲と触れてはいけない範囲
• 判断が分かれたときの優先順位
• 作業後に行うテストと確認

ここが欠けると、FableでもSolでも、推測で埋める部分が増えます。差が付いたのは、前提を渡さずに済むかどうかではなくて、渡した前提からどれだけ外れずに進むかでした。

利用枠の感触は、自分のタスクでしか測れない

Sol Ultraも、利用枠をあまり消費しない設定というわけではありません。それでも私のChatGPT Pro環境では、いくつも作業を続けたあとで「もう少し枠がほしい」と感じる程度に収まっていました。

OpenAIの公式案内でも、Codexの利用量はタスクの規模や複雑さ、モデル、実行場所などで変わるとされています。対象プランでは追加クレジットを使える場合もありますが、「Proなら何回使える」と一律に言える数字はありません。

なので、この利用枠の感触も、2026年7月12日時点の私の環境とタスクに限った話です。短い質問と長時間の移行作業、画像を含む確認とでは、それぞれ消費量が変わります。

Claudeを0ドルにしなかった理由

それでもClaudeに20ドル残したのは、Fable 5の能力そのものを否定する気がないからです。今回試していない、長期間かかる複雑な仕事なら、評価が逆になる可能性もあると思っています。

日常の小さな作業はSol Ultraを中心にして、Claudeは用途を選びながら使い続けることにしました。各社の料金表を見比べて決めた配分ではなく、実際に仕事を渡したときの手戻りと、渡したあとに残った利用枠で決めた配分です。

1回の回答ではなく、完了までの手間を数える

モデル選びで1回の回答の出来だけを見ると、追加指示や修正のやり取り、待ち時間、残りの利用枠が抜け落ちます。私は普段のタスクを何件か渡して、この4点だけを記録していました。

• 最初の指示から完了までに何回修正したか
• 変更範囲と禁止事項を守ったか
• テストと成果物で完了を確認できたか
• 次の仕事を頼める利用枠が残ったか

1つの指示で約30分動いて5時間枠をほぼ使ったFable 5と、同じ種類の仕事を続けて渡せたSol Ultra。この4点を並べたときの差がそのまま、合計を20ドル増やしてでもCodexへ寄せた理由です。

こうして選んだ環境で、いまはWordPressの下書きや画像設定、公開後の確認までAIに任せています。実際の流れは、こちらの運用記事に残しています。

devXserverのWordPress運営をAIで効率化｜任せた作業と人が決めたことXserverのWordPress運営にAIとWP-CLIを使い、15記事のアイキャッチ差し替えや下書き…→

両モデルの利用枠について確認した公式情報

• OpenAI：GPT-5.6 SolとUltra
• OpenAI：Codexの利用量とプラン
• Anthropic：Claude Fable 5
• Claude Help Center：5時間単位の利用上限

そうなると、ここから先に必要なのは実装の続きではなくて、人を集める仕事です。テスターを募って招待し、14日間は参加状態を確かめながらフィードバックをもらう、そこまで含めた運用になります。しかも12人ちょうどに声をかけただけだと、招待の見落としや途中離脱が1人出た時点で条件を割ります。

で、Study AIでは募集目標を15〜20人に置きました。Googleが求める人数はあくまで12人です。15〜20人のほうは、離脱を見込んで私が決めた目標にすぎません。

クローズドテスト「12人・14日」の正確な条件

公式案内は2026年7月17日にあらためて確認しました。2023年11月13日以降に作成された対象の個人デベロッパーアカウントは、本番アクセスを申請する前にクローズドテストを行う決まりです。

Study AIのアカウントは、この対象にそのまま当てはまります。そして、14日間が終われば自動で本番公開、というわけでもないんです。本番アクセスの申請では、テスターをどう集めたか、どのように使ってもらったか、どんな意見を受けて何を変えたかなどを回答します。だから人数だけそろえるのではなく、実際に試してもらうところまで考えておく必要があります。

12人を集めるために15〜20人へ声をかける

条件の人数は12人です。でも、声をかける相手が12人ちょうどだと余裕がありません。応募から14日間の完走までのあいだに、抜ける理由がいくつもあるからです。

• 応募後、招待メールに気づかない
• Google Playの参加リンクを開かない
• 対象端末やGoogleアカウントの条件が合わない
• 14日間の途中でオプトアウトする
• 参加状態にはなったものの、アプリを試していない

どれか1つ起きるだけで、手持ちの12人は11人になります。そう見込んで、初回の募集は15〜20人にしました。人数を増やせば必ず条件を満たせる、という話ではありません。途中で12人を割る可能性を下げながら、実際の意見も集められる人数として決めた数字です。

応募からフィードバックまでの6つの数字

もう1つ、募集の前に数の数え方を決めました。XのDMだけで募集すると、誰に招待を送って、誰が参加していて、誰がいま何日目なのか、すぐ追えなくなります。そこで参加状況を6段階に分けました。

ストア条件の進み具合として見るのは、Play Console側のオプトイン数と継続人数です。応募者が12人を超えていても、Google Playでオプトインしていなければ条件には数えられません。一方、アプリの改善に使うのは利用人数と回答人数のほうです。

募集ページで先に伝える14日間のお願い

募集ページは、アプリの機能紹介だけでは終わらせませんでした。参加を決める前に読めるところに、お願いしたいことと、協力してもらった場合の特典を並べました。

• 参加費は無料であること
• 現在の主な対象はAndroidであること
• 招待後14日以上、テスト参加状態を維持してほしいこと
• 期間中に数回、実際に使ってほしいこと
• 気づいた点を簡単に共有してほしいこと
• 条件を満たして協力を完了した方には、対象アプリで将来提供する有料プランを無償提供すること
• 応募しても必ず参加できるとは限らないこと

お願いと特典を先に読んだうえで応募してもらう、という順序です。フォームの入力項目は、メールアドレス、利用端末、興味のあるアプリの3つにしました。初期表示はStudy AIのAndroid版で、同じ入口からTime LogとChore Points（家事分担アプリ）の待機リストにも登録できます。無償提供の対象は、協力してもらったアプリで将来提供する有料プランです。

Xの反応と応募のあいだにある4段階

Xはテスター募集の主な入口です。ただ正直、投稿へのいいねや表示回数を眺めていても、応募まで進んだかは分からないんですよね。応募までの道のりを分けると、次の4段階になります。

1. XやWordPressの募集リンクをクリックした
2. 募集ページを表示した
3. フォーム送信を始めた
4. 登録を完了した

そこで、リンクには流入元と対象アプリが分かるUTMを付けます。これで、「Xの投稿は見られたが募集ページへ進まない」のか、「募集ページまでは来たもののフォームで離脱した」のかを切り分けられて、直すべきなのが投稿文なのかフォームなのかも判断しやすくなります。

計測では、個人情報の置き場所をはっきり分けました。メールアドレスはメール配信サービスにだけ保存して、アクセス解析には送りません。アクセス解析に残すのは、流入元、対象アプリ、端末、フォーム送信の成否など、募集の流れを直すために必要なイベントだけです。

14日間に置いた5つの連絡の節目

招待リンクを送って終わりでは、参加した人も何をいつ試せばよいか分かりません。かといって毎日連絡する必要もないので、節目を5つだけ決めました。

これはGoogleが決めた連絡回数ではなく、私が用意した運用案です。効かせたいのは最初の参加確認と7日目のフォローで、招待メールの見落としや、操作に詰まっているところを早めに拾うための節目です。

募集投稿の前後で見せる使い方と進捗

フォロワーが少ない段階で「テスターを募集します」とだけ投稿しても、14日間付き合う理由までは伝わりません。なので募集投稿は固定しておいて、その前後では次の内容も発信します。

• Study AIでどのように学習を記録できるか
• 進捗画面で何が分かるか
• なぜ14日間の協力が必要なのか
• テストで確認してほしい操作
• 応募数とテスト準備の進捗
• 受け取った意見をどう改善へ反映したか

お願いだけで終わらせず、実際に使える機能と改善している過程も見せるようにすると、参加したあとに何を試すのかを想像してもらいやすくなります。

公開までに残っている仕事

ふり返ると、Study AIの公開準備はコードの完成では終わりませんでした。12人が14日間参加し続ける条件は自動では満たされないので、募集ページを作り、参加状況を6段階で数え、連絡する日を5つ決める、そこまでが個人開発の公開準備でした。

まず見る数字は、応募者数ではなくPlay Console上のオプトイン数です。そのうえで利用人数と回答人数も確かめて、ストアの条件を満たすだけでなく、公開後も使ってもらえるアプリへ直していきます。

「12人・14日」に対して、いま手元にあるのは15〜20人の募集目標、1つの募集ページ、5つの連絡時点です。応募はStudy AIの募集ページから受け付けていて、メールアドレスと利用端末、興味のあるアプリを送ってもらえれば、招待から14日間の連絡まで、この段取りで進めます。あとは、14日間付き合ってくれる人へこの募集を届けることです。

公式要件の確認先

• Google Play Consoleヘルプ：新しい個人デベロッパーアカウントのアプリテスト要件
• Google Play Consoleヘルプ：テストトラックを設定する

同じ開発ルールが、3か所にありました。repoのREADMEと、AI向けの指示ファイルと、Obsidianのメモです。それぞれ、少しずつ書き方が違います。どれも書いた時点では間違っていませんでした。困ったのは、いまどれが有効なのか分からないことです。更新日も見比べてみたんですが、それだけでは決められませんでした。

AIを使って複数のアプリを開発していると、この「どれが最新か探す時間」がじわじわ効いてきます。ドキュメント管理の問題だと思って、最初は保存場所ばかり考えていました。ただ、実際に大事だったのは場所ではなく、「どれを正本にするか」のほうでした。

そこで行き着いたのが、Obsidianはプロジェクト横断のハブ、各repoは実装の正本という役割分担です。この分け方にしてから、AIが最初に読む入口と、いま有効なルールと、過去の議論が混ざりにくくなりました。コードと一緒に変わる仕様はrepo側にあるので、古いメモをもとに実装してしまう事故も減らせます。

全部Obsidianへ集めて起きたこと

白状すると、最初は「Obsidianへ集めれば、人もAIも迷わなくなる」と思っていました。実際、便利ではあるんです。会話ログも設計メモもタスクもAI向け指示も、1か所で検索できます。ここまでは期待どおりでした。

ずれが出たのは、repoにある実装仕様までObsidianへコピーしてからです。

• コードを変更しても、Obsidian側の仕様が更新されない
• 同じルールが、複数のrepoとObsidianに重複する
• 作業ログに書いた仮説を、AIが確定事項として読む
• 別プロジェクトの、似た名前のメモを参照してしまう
• READMEが長くなり、いまの方針を見つけにくくなる

どれか1つでも起きると、結局は冒頭の「どれが最新か」に戻ってきます。情報が1か所にあるだけでは、「どこを直せば更新完了か」が決まりません。必要だったのは集約ではなく、情報の種類ごとに正本を1つ決めることでした。

分け方の基準は「コードと一緒に変わるか」

で、残る問題は、その正本をどう決めるかです。私が使っている基準は、拍子抜けするほどシンプルです。

迷うのは、Obsidianとrepoの両方に同じ内容が必要になる場面です。そこは無理に重複をなくさず、どちらが正本かを明記したうえで、コピーする範囲を必要最小限にとどめます。

AIに読ませる順番は索引が先、ログが最後

役割を分けただけでは、まだ足りませんでした。AIが毎回すべてのログを読みにいくと、過去の案と現在のルールが同じ重さで扱われてしまうからです。なので、読む順番そのものを固定しました。

1. プロジェクト索引で、対象repoと現在の状態を特定する
2. AI向けガイドで、読む順番と禁止事項を確認する
3. 現行ルールで、いま守る内容を確認する
4. 決定事項で、理由と未決事項を確認する
5. 根拠が必要なときだけ、サマリーやログまでさかのぼる
6. 実装前に、repoのコードとローカル指示を最終確認する

ログを読ませないわけではありません。最初からは読ませない、というだけです。AIはいま有効な短いルールから作業を始めて、判断の理由が要る場面になったら、そこで初めて過去の議論へ戻ります。

1つの文書に2つの仕事をさせない

参照順を決めると、今度は各文書の中身が問われます。READMEに長い設計議論が混ざっていたら、順番を決めた意味が薄れてしまいます。だから、プロジェクトごとの文書は役割で切っています。ファイル名は環境に合わせて変えて構いません。ただ、いま有効な仕様と過去の長い議論だけは、同じ文書へ入れないようにしています。

こう分けておくと、冒頭のように同じルールがREADMEにもAI向け指示にも書かれている状態が、そもそも作られにくくなります。

未確定の情報しかないプロジェクトには、空のルール文書も作りません。空ファイルが1つあるだけだと、「確認した結果、ルールがなかった」のか「まだ何も調べていない」のか、あとから見分けがつかないからです。

雑なログが現行ルールに育つまで

一方で、Obsidian側の書き方はゆるくしています。日次ログや会話には、未確定の案も、失敗も、判断した理由も、そのまま残します。整えるのはあとです。何度も使うと分かったものだけを、順番にルールへ上げていきます。

日次ログ・議論
  ↓
定期サマリー
  ↓
決定事項（決定・理由・参照元）
  ↓
現行ルール
  ↓
repoへ反映する作業指示
  ↓
repoのコード・docs・AI向け指示

方針が変わったときも、ログを消して過去を書き換えることはしません。変更した理由を決定事項に残して、直すのは現行ルールだけにします。こうしておくと、AIが普段読む文書は短いまま、判断の出どころはいつでもたどれます。

repo側にも置くObsidianへの入口

ここまで整えても、穴が1つ残ります。Obsidian側にどれだけ正しいルールがあっても、AIがそのvaultを毎回読めるとは限らないんです。別のPCやツール、CI環境では、そもそもObsidianの場所が分かりません。

そこで、repo内のAI向け指示にも、Obsidianへの参照先をセットで置いています。

• 横断ハブの参照先
• 文書の優先順位
• 作業開始時のgit確認
• 破壊的操作や本番反映の禁止事項
• そのrepo固有のテスト・デプロイ手順

たとえばWordPress運営をAIに手伝ってもらったときは、接続先と反映手順をrepo側に置きました。もしハブとrepoの内容が食い違ったら、実装に近いrepoを優先します。ハブ側の古い記述は、あとから直せば済みます。

始めるなら索引と共通ルールから

「そこまでの仕組みが必要なのか」と思われたかもしれません。最初から全部は必要ありません。いきなり大きなvaultを作らなくても、複数のrepoで同じ判断や指示を繰り返し書くようになった時点で、このくらいの構成から始められます。

knowledge-hub/
  project-index.md
  shared-rules/
  projects/
    project-a/
      ai-guide.md
      rules.md
      decisions.md
      logs/

project-a-repo/
  AGENTS.md
  README.md
  docs/
  src/

まずは索引で対象repoを示し、共通ルールへ複数プロジェクトで使う方針を置き、決定事項に理由を残します。サマリーは、ログが増えて探しにくくなってから足せば十分です。判断の軸は分類の細かさではなく、AIがいまの方針と実装の正本へ迷わずたどり着けるかどうかに置いています。

この仕組みで管理している個人開発プロダクトは、pgsideworksにまとめています。

最初に困っていたのは、3か所に散らばったルールを前に、更新日を見比べていた時間でした。いまは同じ場面が来ても、見比べる必要がありません。実装に使う情報ならrepoが正本、横断の判断と経緯ならObsidianが正本と、先に決まっているからです。文書を増やすより先に決めるのは、この1行です。私のハブづくりは、そこから始まりました。

それでもタグの違いを1つずつ潰して、平均給与、平均勤続年数、平均年齢、離職率を企業横断で見られるWebアプリ「kessan-tracker」として公開できました。載せている数字はすべて、金融庁のEDINETで公開されている有価証券報告書から取っています。

で、いま振り返ると、一番時間を食ったのはデータを集める処理ではありませんでした。EDINET API、XBRL、Next.js、PostgreSQL、AWS Lightsailと道具は並びますが、手がかかったのは、集めた数字の意味をそろえる作業のほうでした。

報告書を1社ずつ開かずに、上場企業の平均年収を比べる

平均年収も平均勤続年数も、実は各社の有価証券報告書を開けば載っています。1社だけ調べるなら、それで十分でしょう。ただ、比べたくなった途端に話が変わります。会社ごとに書類を開いて、年度をそろえて、また次の会社、の繰り返しなので、対象が増えるほど手間もそのまま増えていきます。

kessan-trackerは、この繰り返しを先にまとめて済ませておくアプリです。企業一覧と決算履歴に加えて、ランキングで表示しているのは次の4つです。

• 平均給与
• 平均勤続年数
• 平均年齢
• 離職率

順位こそ付いていますが、投資先や転職先のおすすめではありません。公開書類に載っている数値を、企業と年度をまたいで確かめやすくするためのデータベース、というつもりで作っています。

同じ「平均給与」がタグごとに散らばっていた

XBRLというのは、企業の開示情報を構造化して扱うための形式です。構造化されているんだから、同じ項目は同じタグで取れるはず。取り込みを始める前は、そう信じていました。

実際に流し込んでみると、まずJ-GAAPとIFRSでタグが変わります。銀行や保険のような業種、単体決算か連結決算かでも別のタグになります。同じ意味の数値が別の名前で入っていたり、どのタグを優先するかが会社ごとに違ったりするわけです。

結局、指標ごとに候補タグを持たせて、会計基準や報告書の条件を見ながら値を選ぶ処理を入れました。XMLとして読めたら終わり、ではなかったんです。「このタグは経理上、どの数値を表しているのか」まで確かめないと、見た目が似ているだけの数字を同じランキングに混ぜてしまいます。

ここで効いたのが、本業の経理で身についた科目や開示資料の見方でした。候補タグを探すのも、値を選ぶ処理を書くのも、AIに手伝わせれば速く進みます。ただ、同じ名称に見える値を1つのランキングに並べてよいかどうかは、データの意味を見て私が決めました。

取得はPython、表示はNext.js、保存はPostgreSQL

難所はタグ処理に集中していました。それ以外の仕組みは、取得、表示、保存、公開で役割を分けた構成です。

データベースは、全部入れても約25MBに収まりました。アクセスがまだ少ない個人開発なので、WebもDBも差分更新のバッチも、同じインスタンス1台に同居させています。

「すでにあるインフラ」を勘違いしていた

その1台をどこに置くか。当初はVPSにセルフホストするつもりでした。すでに使っているインフラに合わせれば、移行も運用も楽だろうという算段でした。

ところが、いざ自分の構成を見直してみたら、使っていたのはVPSではなくAWS Lightsailでした。「すでにある環境に合わせる」という方針自体は合っていたのに、肝心の「すでにある環境」を私が勘違いしていたわけです。

そこでLightsailに切り替えて、開発時に選んだ月7ドルの最小プラン1台に、Web、PostgreSQL、取得バッチをまとめました。中身はこうです。

• TLS証明書はCaddyとLet’s Encryptで自動取得する
• SSRのWebとバックエンドは同じプロセスで動かし、CloudFrontは使わない
• EDINETの決算データは毎日のスケジュール実行で差分更新する

月7ドルは契約した当時の料金なので、いまの価格はAWSの公式情報で確認してください。アクセスが少なく、DBも約25MBのいまなら、この1台で足りると判断しています。利用が増えてきたら、Web、DB、バッチを分けるかどうかをそのとき考えるつもりです。

「できたも同然」から、比べられる数字になるまで

EDINETの有価証券報告書は、誰でも取得できます。ただ、約39,000件を集め終えた時点のデータは、ランキングとしてはまだ使いものになりませんでした。横断で比べられるようになったのは、年度をそろえ、会計基準や業種、単体・連結をまたいでタグ候補を整理し、どの値を採用したかをあとから追える形にしてからです。

kessan-trackerは、いまもEDINETのデータを毎日差分更新しています。約3,800社のランキングと各社の決算履歴は、公開中のアプリでそのまま確認できます。

経理のデータを機械に処理させるときに、定型処理へ任せる範囲と人が確かめる範囲をどう分けるか——この線引きの考え方は、経理AIの内部統制の記事にまとめています。

経理経理AIの内部統制はどう設計する？作業と責任、証跡の分け方経理業務をAIに任せても、承認する人の責任まで移るわけではありません。新規取引先と経費精算の実例から、入…→

冒頭の「できたも同然」は、集める工程だけを見た勘違いでした。このアプリで難しかったのは、公開情報を集める処理ではなく、集めた数字の意味をそろえる判断のほうです。その判断を経た約39,000件が、いまのランキングの中身になっています。

画像を作って、アップロードして、投稿のアイキャッチに設定する——そこまで全部通っても、公開ページのOGPが古いままなら、SNSでシェアされたときに前の画像が出てしまう可能性があります。なのでこの作業、「設定した」の時点ではまだ途中で、「反映を確かめた」までいって、ようやく終わります。

この確認を15記事分繰り返すうちに、WordPress運営でAIをどう使うかの線引きが、自分の中ではっきりしてきました。作業を実行できるだけでは足りなくて、実行したあとの状態を再取得して、完了を確認できる作業ほど任せやすいんです。

SSHとWP-CLIで15記事のアイキャッチを差し替えた手順

差し替える前のアイキャッチは、黒い背景に青いネオンを載せたものが多くて、サイト全体が少し暗い印象でした。書いているのは経理、AI活用、WordPress運営の話ですから、業務ブログとして中身が伝わる明るい雰囲気にして、画像だけ見ても記事ごとの違いが分かるデザインへ変えることにしました。

記事ごとにやることは同じで、この繰り返しでした。

• 記事のタイトルと本文を確認する
• 記事ごとに方向性を変えて画像を生成する
• 画像をXserverへ転送する
• wp media import でメディアへ登録し、altなどの情報を設定する
• _thumbnail_id を更新し、公開ページの og:image まで確認する

これを15記事分、繰り返しました。管理画面から手でやるなら、画像を保存して、メディアへアップロードして、投稿の編集画面で設定して、公開ページを確認して。これを記事の数だけやり直すことになります。SSHでXserverへ入ってWP-CLIを使える環境だったおかげで、この一連の操作はまとめてAIに渡せました。

ただ、まとめて渡せた理由を「画像作成が簡単だから」と読まれると、そこは違うんです。添付IDにアイキャッチID、公開ページのOGPと、終わったかどうかを外から確かめる材料が最初からそろっていたからこそ、渡せた作業でした。

WordPress運営でAIに任せやすかった作業の共通点

WordPressにAIを使うと聞くと、記事本文の自動生成が真っ先に浮かぶと思います。ただ、このブログで実際に負担が減ったのは、本文を書く前後に散らばっている細かな運営業務のほうでした。

XserverへSSHで入ってWP-CLIが使える状態なら、投稿もメディアもコマンドで操作できます。しかも、操作したあとの状態を、同じ方法で引き出して確かめられます。任せやすさの差は、ここで生まれていました。

15記事を一気に進められたのも、表でいうと右端の列、つまり完了の確認方法が先に埋まっていたからです。裏を返せば、そこが埋まらない作業は、AIが「終わりました」と言ってきても鵜呑みにはできない、ということでもあります。

下書きを入れた記事は、そのまま公開できるのか

下書きの投入も、任せやすさでいえば筆頭クラスです。ローカルでタイトルと抜粋、Gutenberg向けのブロックHTMLを用意して、Xserverへ転送し、WP-CLIで下書きとして登録してもらいます。登録後の編集URLまで返してもらえば、管理画面を開いて本文を貼り付ける工程が丸ごと消えます。

この投入までは、本当に速く進みます。ただ、「正しく登録された」と「このまま公開できる」のあいだには、まだ距離がありました。

AIに頼めるのは、見出しの整理、文のねじれの修正、読みにくい段落の分割あたりまでです。次の3点だけは、自分の目で確かめる必要がありました。

• 実際に経験した内容と文章がずれていないか
• 読者に持ち帰ってほしい判断が明確か
• 一般論だけでなく、このブログで公開する意味があるか

古い記事のリライトでは、ここが特に効いてきます。文章をきれいに直すだけだと、元の記事に入っていた経験や迷いまで一緒に薄まってしまうことがあるんです。なので、構成や表現は大きく動かしてもらいつつ、事実と主張だけは先に自分で決めておくようにしました。この分け方なら、がらっと書き換えても記事の中身までは消えませんでした。

内部リンクと校閲で頼んだ範囲

内部リンクの候補出しは、公開済み記事のタイトルとslugを一覧にして渡しておくと頼みやすくなります。会計ソフトの記事からAPIの記事へ、AI前提の内部統制の記事から経費精算AIの記事へ、WordPressテーマの記事からブログ運営の記事へ、という具合に、内容のつながりを拾って提案してくれます。

校閲で頼んでいたのも似た形の仕事で、表記ゆれ、長すぎる文、見出しと本文のずれ、メタディスクリプションの長さ、読みにくい箇条書きといった箇所を見つけてもらいます。

とはいえ、候補に挙がったリンクが、読者にとって本当に必要かどうかは別の問題です。リンク先がいま読んでいる読者の疑問を補えるかどうかは、本文を読みながら自分で判断しました。

完了の条件まで入れた依頼文の書き方

依頼の出し方にもコツがあります。「アイキャッチを設定して」とだけ頼むと、どの状態になれば完了なのかが曖昧なまま作業が始まってしまいます。実際の依頼は、こういう文面にしていました。

この記事に合うアイキャッチを作成し、WordPressへアップロードして、投稿ID 7152のアイキャッチに設定してください。設定後は、添付IDとアイキャッチIDを取得し、公開ページの og:image に新しい画像が反映されていることまで確認してください。投稿の公開状態は変更しないでください。

この文面だと、画像ができた時点でも、WordPressへ登録できた時点でも、まだ終わりではありません。公開ページへの反映まで確認できて、はじめて完了です。冒頭で書いた「反映を確かめた」がゴール、というのはこの意味なんです。

下書きの投入も同じ考え方で、登録後にタイトル、抜粋、本文、公開状態を再取得して、ローカルの原稿と一致しているかを照合するところまで、1回の依頼に含めてしまいます。

15記事の差し替えで最後まで自分が決めたこと

振り返ると、画像の生成、転送、メディア登録、投稿への設定、OGPの確認と、手が動く部分は全部AIで進んでいます。それでも、サイト全体を明るい雰囲気へ変えるかどうか、生成された画像が各記事の内容に合っているか、その状態で公開してよいか——ここは最後まで自分で決めました。

そして任せる範囲は、「文章か画像か」という作業の種類では結局分けられませんでした。分かれ目になったのは、この2点です。

結果を再取得して完了を確認できるか。記事に価値があるか、公開してよいかまで機械的に判定しようとしていないか。

この2点で眺めていくと、任せられる作業が見つけやすくなります。ちなみに、複数プロジェクトのルールや判断をAIが継続して参照できるようにする仕組みは、Obsidianで組んだ開発ハブの記事に書いています。

devObsidianでAI開発の文書を管理する｜repoとの役割分担AIを使って複数のrepoで開発していると、READMEとObsidianのメモが少しずつずれてきます。…→

これから試すなら、まず1記事だけ、アイキャッチの設定から og:image の確認までをひとまとめで頼んでみてください。返ってきた添付IDと公開ページを自分の目でも確かめられたら、次からは同じ作業を任せやすくなるはずです。

公開範囲もひかえめではありません。仕訳の取得、作成、更新、削除ができて、試算表、マスター、証憑まで扱えます。freee会計のほうには、OAuth 2.0で取引や振替伝票などを読み書きできるPublic APIが以前からありますから、「APIが使えるのは片方だけ」という前提は、もう成り立たないわけです。

比較の結論は、こうやってこちらに知らせもなく古びていきます。だから私は、会計ソフトを「APIあり」の1項目で選ぶのは危ういと思うようになりました。確かめたいのは有無ではなく、いまの契約と権限で必要なデータを読み書きできて、その結果まで検証できるかです。

連載「経理をAIに任せる」（全4回）

1. 経理AIの内部統制をどう設計する？作業・責任・監査証跡の分け方
2. 新規取引先チェックをAIで自動化｜閉鎖・合併済み法人を検知した方法
3. 経費精算のレシート照合をAI-OCRで自動化｜分割計上も検知
4. 会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準（この記事）

振り返ると、この連載の3つの実践も、申請の取得、公式情報との照合、証憑の取得、結果の整理を、全部APIでつないでいました。裏を返せば、接続先からデータを取り出せなかったら、AIがどれだけ賢くても、同じ流れは作れなかったはずです。

AIは会計データまで自力では届かない

生成AIは、会計ソフトの中のデータへ勝手にアクセスできるわけではありません。APIやMCP、許可された画面操作といった、外部システムとつながる手段が別に要ります。

ただ、APIが公開されているだけでは、まだ足りません。認証したユーザーに必要な権限がなければ、取得も更新もできないからです。会社として利用を認めるのか、誰の権限で動かすのか、書き込みをどこまで許すのか——このあたりは、製品を選ぶより先に決めておく話です。

NetSuiteやSAPのような大手ERPにも、APIそのものはあります。それでも、現場ですぐ使えるとは限りません。契約や権限、連携基盤、SIerとの役割分担まで整えて、ようやく使える状態になることもあります。

会計ソフトのAPIを比べる4つの基準

接続と権限まで含めて考えていくと、比べる項目はだいたい絞れてきます。私が確認しているのは、この4つです。

機能表の丸印を数えても、自社で使えるかどうかは分からないんですよね。なので、自動化したい業務を1つ選んで、この4つに当てはめてみます。仕訳を任せたいなら、「仕訳APIあり」で止めずに、対象年度の仕訳を取得できるか、作成や更新に対応しているか、必要な補助科目を扱えるか、誰の権限で認証するか、更新後に再取得して確かめられるかまで見て、やっと比較と呼べる状態になります。

freee会計APIは契約プランで使える範囲が変わる

freeeは以前からPublic APIを公開していて、認証はOAuth 2.0です。会計APIには、取引、振替伝票、取引先、勘定科目、経費精算、支払依頼など、取得と更新の両方に対応したエンドポイントがそろっています。

ただ、使えるAPIや項目は契約プランで変わるんです。公式リファレンスに載っている事業所とアプリケーションごとの1日上限は、法人エンタープライズが10,000回、法人アドバンスが5,000回、それ以外は3,000回です。総勘定元帳APIのように、対象プラン自体が限られる機能もあります。

つまり「freeeなら全部使える」という話ではなくて、必要なエンドポイントをいまの契約で使えるかどうかを、1本ずつ見ていくことになります。一方で、一般の開発者でも公式リファレンスとアプリ登録から検証を始められるので、自分で試すハードルは低いほうだと思います。

いつの間にか一般公開になっていたマネーフォワード会計API

私の整理をひっくり返した側の、マネーフォワード クラウド会計です。いまの公式案内では、クラウド会計や確定申告の利用者なら、士業でも個人事業主でも法人でも、APIを利用できます。追加料金もかかりません。

操作の範囲もかなり広くて、仕訳の取得、作成、更新、削除のほか、取引明細の作成や証憑の保存と添付ができて、貸借対照表、損益計算書、月次推移、勘定科目、部門、取引先といったマスターまで扱えます。認証はOAuth 2.0とAPIキーによる方法が、開発者サイトで案内されています。

それと、AIツールから会計データを扱えるMCPサーバーも用意されています。APIとMCPは向いている用途が同じではないので、定期バッチや他システムとの連携にはAPI、AIと対話しながら確認する場面にはMCP、という使い分けになると思います。

NetSuiteは同時実行の上限がライセンスと連動する

大手ERPの例としてNetSuiteを見ておくと、こちらはWebサービスの同時実行の上限が、サービス階層とSuiteCloud Plusのライセンス数に連動しています。必要なAPIがそろっていても、大量処理や複数の連携を同時に動かすつもりなら、アカウント全体の上限と割り当てを確かめてからでないと始められません。

これは「大手ERPは使えない」という意味ではありません。権限管理や同時実行の制御が細かいぶん、現場で小さく試すまでの調整も増える、ということです。処理量の多い企業では、むしろその統制や拡張性のほうが必要になります。

製品名ではなく、業務を1つ通した結果で決める

freeeもマネーフォワードも会計APIを公開しているいま、製品名だけで「AI経理に向いているのはこちら」と決めるやり方は、もう成り立ちません。私が候補を比べるなら、1つの業務を次の順で通してみます。

1. 自動化したい業務を1つ選ぶ
2. 必要な取得項目と書き込み項目を洗い出す
3. 検証環境または読み取り専用でAPIを試す
4. 件数上限、権限、追加費用、更新後の確認方法を記録する
5. 例外時に止まり、人の確認に戻せることを確かめる

この5つは、APIの公開状況がまた変わっても、そのまま使えます。冒頭の「一般利用できない」という整理がひっくり返ったように、比較表の中身はこれからも動くはずです。でも、業務を1つ通して確かめる手順のほうは動きません。AIに任せられる範囲を決めるのは、モデルの性能だけではなくて、接続先がどこまで公開されていて、自社がどの権限を与えられるか、なんです。

ただし、APIで処理できることと、AIに承認の責任まで渡してよいことは、別の話です。作業と証跡をどう残すか、例外や人の承認をどう扱うかは、連載の最初の記事に書いています。

経理経理AIの内部統制はどう設計する？作業と責任、証跡の分け方経理業務をAIに任せても、承認する人の責任まで移るわけではありません。新規取引先と経費精算の実例から、入…→

2026年7月17日に確認した公式情報

• freee：Public API／会計APIリファレンス
• マネーフォワード：クラウド会計API／開発者ドキュメント／MCPサーバー
• NetSuite：Concurrency Governance Limits

合計そのものは合っています。レシートの合計と申請全体を見比べるだけの確認なら、まず素通りする組み合わせです。ただ、この仕組みが突合するのは合計ではなく、明細ごとの金額です。明細を1行ずつレシート内の文字から探しに行くので、「金額が見つからない」という根拠付きで、申請は自動的に要確認へ回ってきました。

で、この照合の仕組みなんですが、レシートを全部AI-OCRに読ませているわけではありません。文字を取り出せるPDFはPythonで照合して、画像やスキャンだけをClaudeに読ませています。分割計上や税率の混在、適格請求書に当たらない証憑が引っかかったら、最後は人が確認する流れです。

連載「経理をAIに任せる」（全4回）

1. 経理AIの内部統制をどう設計する？作業・責任・監査証跡の分け方
2. 新規取引先チェックをAIで自動化｜閉鎖・合併済み法人を検知した方法
3. 経費精算のレシート照合をAI-OCRで自動化｜分割計上も検知（この記事）
4. 会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準

前回の新規取引先チェックでは、公式情報との照合が中心でした。全件を確認するのは今回も同じなんですが、経費精算では、文字を扱う機械処理と画像を読むAIを使い分けています。

経費精算の明細とレシートは何を突合するか

仕組みの中身は、聞いてしまえば単純です。申請明細と添付された証憑を1件ずつ対応させて、次の4項目を突合します。

• 税込金額
• 利用日または発行日
• 税区分と税率
• 適格請求書発行事業者の登録番号

件数が増えてくると、1枚ずつ「それらしい」と眺める確認では、この4つのどこかに不一致が紛れやすくなります。だったら、すべての明細に同じ条件を当てて、引っかかったものだけを人へ返すほうが確実だろうと考えて、この形にしました。

AI-OCRの前に、Pythonでテキスト層を読む

処理の入口はバクラクです。申請中の経費精算を取得して、明細ごとに金額、日付、税区分と、添付されたレシートを取り出します。ベンダーAPIに関わる部分なので、コードは擬似コードにしています。

# バクラクAPIで「申請中の経費精算」を取得し、明細ごとに
# 金額・日付・税区分・レシート（添付ファイル）を取り出してDLする
applications = bakuraku.fetch_requests(status="IN_PROGRESS", form="経費精算申請")
receipt_bytes = bakuraku.download(f"/workflow/user_upload_files/{file_id}/file")

取り出したレシートは、いきなりAIには渡しません。PDFにテキスト層が残っていれば、PyMuPDFで文字をそのまま取れるからです。文字を取得できない画像やスキャンは空文字を返しておいて、後段のAI-OCRへ回します。

import fitz  # PyMuPDF

def extract_text(path: str) -> str:
    """PDF/画像からテキストを抽出する。テキスト層が無ければ空文字。"""
    try:
        with fitz.open(path) as doc:
            return "".join(page.get_text() for page in doc)
    except Exception:
        return ""

文字が取れたら、申請明細の税込金額がその中にあるかを探します。ここで効いてくるのが、レシートの数字の癖です。桁の間に空白や改行が入っていることがあるんです。なので、空白とカンマを除いてから突合しています。

import re

def amount_in_text(amount: int, text: str) -> bool:
    """金額がテキストに出現するか（空白・カンマ・改行を吸収）。"""
    if not amount:
        return None
    flat = re.sub(r"[\s,，]", "", text)      # 空白とカンマを全除去
    return str(abs(int(amount))) in flat

この突合で分かるのは、あくまで「金額の文字列があるか」までです。証憑全体が妥当だと保証してくれるわけではありません。それでも、取得できる文字を毎回AIに解釈させるより、同じ条件で速く再実行できます。

ClaudeのOCRに回すのは、文字を取れない画像だけ

肝心の分岐は、if文がひとつあるだけです。テキスト層があればPythonで金額を探して、なければ「要OCR」としてClaudeへ渡します。

if has_text_layer:
    verdict = "OK" if amount_in_text(amount, text) else "要確認(金額不一致)"
else:
    verdict = "要OCR(Claude)"     # ← 画像はここでAIに回す

AIの仕事として残したのは、画像から文字を読むことと、証憑の種類や税率の混在を文脈から整理することです。逆に、テキスト層のある証憑まで同じ流れに乗せると、判定がぶれやすくなるうえに、AIの利用量も増えていきます。読ませる範囲を絞ったのは、そのためです。

全件突合で引っかかった3つの要確認パターン

この仕組みを実際の申請に当てたところ、目視では見落としやすいパターンが3つ見つかりました。申請者や金額などの内容は伏せています。

合計は合っているのに、明細の金額がない分割計上

1つめが、冒頭のレシートです。1枚の合計を複数の明細に分けてあるので、合計額は正しいのに、明細単位で突合すると金額不一致になります。ただ、この不一致がそのまま不正や誤りを意味するわけではありません。機械にできるのは不一致を指摘するところまでで、按分の理由や申請方法が妥当かどうかは、人が確認します。

申請は10%、レシートには8%が混ざる税率

2つめは税率の混在です。申請明細は課税10%なのに、レシートには軽減8%や対象外が含まれているパターンです。レシートに何が書かれているかを文脈から読み取って整理する部分は、AIに任せられます。整理した税区分の候補は、要確認の根拠として申請に添えて返します。

登録番号のない予約確認書やフリマの画面

3つめは、適格請求書に当たらない証憑です。予約確認書やフリマの取引画面など、登録番号のない証憑が添付されていると、番号の有無で引っかかります。ただ、そういう証憑しかない申請をどう扱うかは、会社の規程の話です。なので仕組みの側は、読み取った証憑の種類と、登録番号がないという事実を添えて申請を返すところまでにしています。

Python、AI、人の担当と止める条件

担当の線引きでは、「誰が何をやるか」だけでなく、「どこで止めるか」もあわせて決めてあります。

機械とAIに任せたのは、すべての明細を同じ条件で確認して、要確認の根拠を添えて人へ返すところまでです。その先の承認と差し戻しは、人が会社の規程と責任に基づいて決めます。さっきの3パターンで最後の判断がどれも人に残っているのは、この線引きのとおりに動いた結果です。

コードの側にも決めごとがあります。経費精算と支払申請に共通する取得、文字抽出、正規化は、共通ヘルパーへ切り出して使い回しています。それから、同じ例外が繰り返されたときは、AI向けの注意書きを足して済ませず、判定コードを直してテストも追加するようにしています。

これから同じ照合を組むなら、最初からAI-OCRを全件に当てる必要はありません。まずはテキスト層のあるPDFだけを対象に、金額の突合をif文ひとつで動かしてみてください。それだけでも、明細単位の不一致は拾えます。文字を取れない証憑が実際にどれくらい混ざるかを見てから、AIに読ませる範囲を決めても遅くありません。

この実践で見えてきた会計ソフト選びの条件は、連載最終回のAPI比較で整理しています。

経理会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準会計ソフトをAPIで比較するときに見たいのは、利用条件、読み書きの範囲、制限と料金、検証と統制の4点です…→

この「残り半分」で引っかかった申請が、実際にありました。新規取引先の登録申請をAIにチェックさせていたときのことです。申請された商号は登記上の商号と一致しています。それなのに、入力されていた法人番号は合併で閉鎖された法人のもので、存続会社には別の法人番号がありました。商号だけを見ていたら、そのまま通していたかもしれません。

この不一致を見つけたのはAIです。バクラクの申請内容と国税庁の情報を照合させて、法人番号の形式を確かめたうえで、商号、インボイス番号、閉鎖年月日、承継先を調べ、問題のある申請だけを「要確認」に振り分けてもらいました。

といっても、会社が実在するかどうかをAIの知識だけで推測させたわけではありません。法人番号は計算式で検算し、会社情報は国税庁の公式Web-APIから取得します。そして、最後に承認するか差し戻すかを決めるのは人です。

連載「経理をAIに任せる」（全4回）

1. 経理AIの内部統制はどう設計する？作業と責任、証跡の分け方
2. 新規取引先チェックをAIで自動化｜合併で閉鎖された法人番号を見つけた方法（この記事）
3. 経費精算のレシートと明細を、AIに全部突合させてみた
4. 会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準

この実例でAIに任せたのは、公式情報を集めて不一致を見つけるところまでです。引っかかった申請をどう扱うかは、人が根拠を見て決めました。

新規取引先チェックで見ている4つの項目

そもそも新規取引先の登録申請で私が確認しているのは、少なくとも次の4つです。

• 法人が実在するか
• 申請された商号と登記上の商号が一致するか
• インボイス登録番号と法人番号が整合するか
• 法人番号が正しい形式で、その法人が閉鎖または合併済みではないか

13桁がそろって見えても、入力ミスはあり得ます。それに今回のように、商号は合っているのに中の番号だけが古い、というケースも実際にあるわけです。だから、番号の形式を検算する工程と、公式情報と照合する工程を分けることにしました。

申請の取得と、法人番号13桁の検算

流れの最初は、バクラクから申請中の新規取引先申請を取ってくるところです。ベンダーAPIに関わる部分は、公開できる範囲に絞った擬似コードにしています。

# バクラクAPIで「申請中の新規取引先申請」を取得し、
# 各申請から 法人番号・取引先名・インボイス番号 を取り出す
applications = bakuraku.fetch_requests(status="IN_PROGRESS", form="新規取引先申請")

取り出した法人番号は、まず手元で検算します。法人番号は、12桁の基礎番号の前にチェックディジット1桁を付けた13桁で、計算方法は国税庁が公開しています。つまり、番号が形式どおりかどうかは、APIに聞くまでもなく確かめられます。

def validate_corporate_number(number: str) -> bool:
    """法人番号13桁のチェックディジットを検証する。"""
    if not number or len(number) != 13 or not number.isdigit():
        return False
    check_digit = int(number[0])
    base = number[1:]                      # 下位12桁が基礎番号
    total = 0
    for i, ch in enumerate(reversed(base)):
        weight = 2 if i % 2 == 1 else 1    # 右から 奇数桁=1, 偶数桁=2
        total += int(ch) * weight
    return (9 - (total % 9)) == check_digit

ただ、この検算で分かるのは「番号が計算式に合っているか」だけなんです。その法人が実在するのか、いまも同じ番号が有効なのかは、ここでは何も分かりません。

実在と閉鎖状態は、国税庁の法人番号Web-APIで照合する

法人の実在と商号、閉鎖状態は、国税庁の法人番号Web-APIに問い合わせます。Web-API Ver.4はCSV（Unicode）を指定して法人情報を取得でき、利用には無料で発行されるアプリIDが必要です。

import csv, requests

NTA_API = "https://api.houjin-bangou.nta.go.jp"

def nta_lookup(numbers: list[str], app_id: str, version: str = "4") -> dict:
    """国税庁 法人番号Web-APIで 実在・商号・閉鎖 を照会する。"""
    resp = requests.get(
        f"{NTA_API}/{version}/num",
        params={
            "id": app_id,                 # 無料発行のアプリID
            "number": ",".join(numbers),  # 最大10件まとめて
            "type": "02",                 # CSV(Unicode)で受け取る
            "history": "0",               # 最新の登記のみ
        },
    )
    resp.raise_for_status()
    records = {}
    for row in csv.reader(resp.content.decode("utf-8").splitlines()):
        if len(row) <= 20:
            continue                      # ヘッダー行などをskip
        records[row[1]] = {               # row[1] = 法人番号
            "name":      row[6],          # 商号
            "closeDate": row[18],         # 閉鎖年月日（合併・解散など）
            "successor": row[20],         # 承継先の法人番号
        }
    return records

今回の件で効いたのは、このうち閉鎖年月日と承継先の項目でした。商号が一致するかだけでなく、「その番号がいまも生きているか」まで同じ照会で確認できます。あとは取得した情報と申請内容を比べて、問題がなければOK、条件に1つでも当てはまれば要確認、という判定にしました。

issues = []
if not validate_corporate_number(corp):
    issues.append("法人番号CD不正")
if invoice and invoice != "T" + corp:
    issues.append("インボイス番号不整合")
if record is None:
    issues.append("国税庁に該当なし")
elif record["closeDate"]:                       # ← ここが効いた
    issues.append("閉鎖/合併（承継先: " + (record["successor"] or "不明") + "）")
elif normalize(client_name) != normalize(record["name"]):
    issues.append("商号不一致")

verdict = "要確認" if issues else "OK"

見てのとおり、法人番号や会社情報をAIの知識で判定させている箇所はありません。判定材料は、計算結果とAPIのレスポンスだけです。それでも、商号の表記をそろえる方法や例外条件が間違っていれば、誤判定は起きます。だから、コードが動いたかどうかだけでなく、出てきた判定結果まで確かめるようにしています。

商号は合っていた。それでも閉鎖年月日が返ってきた

で、冒頭の申請です。APIの応答には閉鎖年月日が入っていて、合併後の承継先として別の法人番号も返ってきました。申請された商号と登記上の商号を見比べても、違和感はどこにもありません。番号の中身だけが古かったわけです。

この申請は自動承認せず、閉鎖年月日と承継先を根拠に「要確認」で止めました。申請者へ差し戻したのは私です。AIに任せたのは、全件を同じ条件で調べて、人が見るべき申請を絞り込むところまででした。

アプリIDがない間はWeb検索で暫定確認

国税庁のWeb-APIには、1つ前提があります。無料とはいえ、アプリIDが発行されるまでは使えないことです。発行を待つ間など、すぐにAPIを使えない場合のために、法人番号データベースの houjin.info やhoujin.jpをAIに検索させて、商号や所在地、閉鎖状態、承継先を確認する手順も用意しました。

• 番号から商号、所在地、登記状態、承継先を確認する
• 申請された商号や住所と照合し、不一致があれば「要確認」にする
• 参照URLと確認日を残し、番号をAIに生成させない
• 重要な判断は国税庁の公表サイトまたは公式APIで再確認する

この手順はプロジェクトのREADMEに置いて、AIが作業を始めるときに読める場所にしています。とはいえ、第三者サイトの更新時点や表示内容が、公式情報と同じとは限りません。なので位置づけは、あくまで暫定確認と根拠集めです。APIの代わりにずっと使うつもりはありません。

照合コードもAIに書いてもらった

ここまで載せたコードを、私がすべて手で書いたわけではありません。確認したい項目と正常例、異常例、出力形式をAIに渡して、初稿と修正案を作ってもらいました。私がやったのは、チェックディジットの計算式とAPIのレスポンス、実際の判定結果を確かめることです。

実装を一から書けない私でも、業務の要件を説明して結果を確かめることで、こういう確認ツールを作れるようになりました。もっとも、コードが動いたからといって、そのまま会社の承認ルールに使えるとは限りません。

同じ考え方は経費精算にも広げていて、レシートと申請明細は全件突合し、画像しかない証憑だけをAI-OCRに回しています。

経理経費精算のレシート照合をAI-OCRで自動化｜分割計上も検知経費精算のレシートと申請明細を全件突合しました。文字を取り出せるPDFはPythonで照合し、画像だけを…→

振り返ると、商号が合っていた閉鎖法人の申請を止められたのは、AIの推測が当たったからではありません。13桁の検算と国税庁の情報を根拠に「要確認」で止め、最後は人が差し戻すという流れを、先に作っておいたからです。

実装時に確認した公式情報

• 国税庁：法人番号システムWeb-API Ver.4
• 国税庁：チェックディジットの計算