下書きを作る。アイキャッチを設定する。過去記事を確認する。内部リンクを入れる。メタディスクリプションを整える。公開後にOGP画像が反映されているか見る。

こういう作業を毎回ブラウザの管理画面だけでやると、地味に時間がかかります。そこで最近は、Xserver上のWordPressにSSH接続し、デスクトップアプリからAIへ指示して、運営業務の一部を手伝わせています。

AIに任せられるのは「記事を書くこと」だけではない

AI活用というと、すぐに「本文を自動生成する」話になりがちです。

もちろん本文のたたき台を作ることもできます。でもブログ運営で本当に効くのは、本文生成よりも周辺作業の自動化かもしれません。

• ゴミ箱や下書きにある記事を一覧化する
• 記事タイトル、slug、公開状態を確認する
• 古い記事を新テーマ向けのHTMLに整える
• アイキャッチ画像を記事内容に合わせて作る
• WordPressに画像をアップロードして、記事のアイキャッチに設定する
• 内部リンクやメタディスクリプションを確認する

このあたりは、AIと相性がいいです。人間が毎回クリックして確認していた部分を、AIがWP-CLIやファイル操作でまとめて処理できます。

XserverにSSH接続できると、できることが増える

Xserverでは、SSH接続とWP-CLIが使える環境なら、WordPressの投稿やメディアをコマンドから操作できます。

たとえば、AIにデスクトップアプリ上で次のように頼めます。

この記事の内容に合うアイキャッチを作って、WordPressにアップロードして、投稿ID 7152 のアイキャッチに設定して。公開ページのOGP画像も確認して。

人間がやると、画像を作る、保存する、管理画面を開く、メディアにアップロードする、投稿編集画面で設定する、公開ページで確認する、という流れになります。

AIに任せる場合は、画像生成、サーバー転送、wp media import、_thumbnail_id の更新、公開ページの og:image 確認まで一気に進められます。

下書き作成もAIに任せられる

記事の下書き投入も、AIに任せやすい作業です。

ローカルでGutenberg向けのHTML、タイトル、抜粋を作り、サーバーへ転送して、WP-CLIで下書き投稿として作成する。これだけなら、人間が管理画面に貼り付ける必要はありません。

• タイトル案を作る
• 抜粋を120文字前後で作る
• 本文をブロックHTMLとして整える
• 下書きとしてWordPressへ投入する
• 管理画面の編集URLを返す

ここまでAIにやってもらえば、人間は管理画面で最終確認し、必要な部分だけ直せばよくなります。

ただし、記事の中身はリライトが必要

とはいえ、AIに本文をそのまま任せればよいかというと、そこは微妙です。

AIは構成を整えるのが得意です。見出しを作る、表を作る、文章のねじれを直す、読みにくい段落を整理する。こういう編集作業はかなり頼れます。

一方で、「その記事に自分の経験が入っているか」「読んだ人に何を持って帰ってほしいか」「このブログらしい言い方になっているか」は、人間が見た方がいいです。

特に旧記事のリライトでは、AIが文章をきれいにするだけだと、どこか薄い記事になりがちです。古い記事の中にある自分の経験や失敗談を拾い直し、今の視点で書き換える必要があります。

内部リンクと校閲はかなり任せやすい

一方で、内部リンクの設定や文章の校閲はAIに任せやすいです。

たとえば、公開済み記事のslugやタイトルを一覧化しておけば、AIは新しい記事の文脈に合う関連記事を探せます。

• 会計ソフトの記事からAPIの記事へリンクする
• AI前提の内部統制の記事から経費精算AIの記事へリンクする
• WordPressテーマの記事からブログ運営の記事へリンクする

こういうリンク候補を出し、本文中の自然な位置に入れる作業はAI向きです。

文章校閲も同じです。表記ゆれ、長すぎる文、見出しと本文のズレ、メタディスクリプションの長さ、読みにくい箇条書きなどは、AIにチェックさせるとかなり拾えます。

アイキャッチ画像の差し替えは特に相性がいい

今回かなり効果を感じたのが、アイキャッチ画像の差し替えです。

既存の記事では、黒背景に青いネオンのような画像が多く、少しダークな印象に寄っていました。記事の内容は経理、AI活用、WordPress運営なので、もう少し明るく、業務ブログとして読みやすい雰囲気にした方が合いそうです。

AIに記事タイトルと内容を読ませ、記事ごとに画像の方向性を変えて生成し、WordPressへアップロードしてアイキャッチに設定しました。

これは人間がやるとかなり面倒ですが、AIに任せると流れ作業にできます。しかも公開ページの og:image まで確認できるので、SNSで共有したときの見え方もチェックできます。

ブログ運営AI化の現実的な分担

実際にやってみると、AIに任せるべき部分と、人間が見た方がいい部分は分けた方がよさそうです。

まとめ：AIはブログ運営の裏方にかなり使える

AIにブログ運営を任せるというと、どうしても「AIが記事を全部書く」話に見えます。

でも実際には、記事を書く前後の作業こそ効率化しやすいです。

XserverにSSH接続できて、WP-CLIでWordPressを操作できるなら、デスクトップアプリからAIに指示するだけで、下書き作成、アイキャッチ設定、内部リンク確認、文章校閲、公開後チェックまでかなり進められます。

ただし、記事の中身はやはり人間が見た方がいいです。AIは文章を整えられますが、その記事を公開する意味や、自分の経験から出る一言までは、運営者が入れた方が強くなります。

なので、現実的にはこうです。

記事の魂は人間が入れる。運営の手間はAIに持たせる。

この分担が、個人ブログでAIを使う一番ちょうどいい落としどころかもしれません。

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

1. 「経理はAIに任せられない」の先へ——AI前提の統制を、いま設計する
2. 新規取引先チェックをAIに任せたら、合併で消えた会社を見つけてきた
3. 経費精算のレシートと明細を、AIに全部突合させてみた
4. AI前提の経理は、会計ソフトを「APIが開いているか」で選ぶ（この記事）

たび

AIの手足はAPIです。頭がよくても、手が届かなければ作業はできない。だからツールは「開いてるか」で選びます。

AIの限界は「頭」じゃなく「手」

生成AIは賢い。でも、あなたの会計システムのデータを勝手に取ってきて書き戻すことはできません。そこにAPIが無ければ、結局は人が画面をポチポチするしかありません。AIの賢さは、APIが無ければ宝の持ち腐れになります。

選定軸は「機能」から「開かれたAPI」へ

これまでは機能・価格・サポートで選んできました。AI前提なら最優先で見るのは「AIが触れるAPIを、現場の自分たちで叩ける形で開いているか」です。機能が多くてもAPIが閉じていれば、AIは仕事を手伝えません。

大手ERPは「APIが無い」のではなく「自走で叩けない」

誤解されがちですが、大手のクラウドERP（SAP・NetSuite・奉行クラウド等）はAPIを持っています。問題はその先です。多くの基幹システムやオンプレ環境では、API連携がSIer頼み・iPaaS前提・権限とコストの壁で、経理現場が自分でサッと叩ける状態にありません。レガシーなオンプレに至っては、そもそも外から触れないことも多いです。

「APIがある」だけでは足りない——4つの落とし穴

APIが公開されていても、次のどれかに引っかかると実用になりません。

1. 従量課金：呼ぶほど・人数が増えるほど課金。例えばMFは基本3名まで、4名以上は1名 月300円〜、AI-OCRは101件目から1件20円。NetSuiteはAPIの同時実行数を増やすのに有償ライセンスが要る——スループットを金で買う構造です。
2. 使えるモジュールの制限：肝心の機能だけ非対応、があります。MFは請求書・経費・給与・債務支払のAPIは公開ですが、クラウド会計のAPIはクローズド（士業パートナー限定）。「周辺は開いてるのに本丸が閉じてる」型です。
3. 操作の制限：読み取りだけ可・書き込み不可、一部項目しか触れない、というケース。「取得はできるが登録できない」だと、AIに作業させる用途では片手落ちです。
4. プラン・件数の上限：低プランはリクエスト数や件数に上限。MFは請求書APIが低プランで各帳票100リクエスト、ひとり法人は仕訳500件/年。freeeもレート制限はあります（ただし通常の自動化なら回る範囲・読み書き可）。

国産クラウド会計：freee と MF の決定的な差

ここは感覚ではなく、公開仕様の差で語れます。

• freee：会計APIを公開していて、freeeアカウントがあれば誰でもアプリ登録してすぐ使えます（事前許可なし・OAuth2）。仕訳や取引を読み書き両方できる＝AIに会計作業を任せやすい。レート制限はありますが通常の自動化なら回る範囲です。
• マネーフォワード（MF）：請求書・経費・給与・債務支払のAPIは公開していますが、クラウド会計のAPIは一般公開されていません（クローズド／士業パートナー限定）。さらに公開APIも低プランはリクエスト数・仕訳件数に上限があり、人数に応じた従量課金も乗ります。

今後、APIの公開度が「標準」になる（見立て）

AIで生産性を出すのが当たり前になれば、会計APIを閉じたツールは選ばれなくなります。そうなればベンダーも開く方向に動かざるを得ません。だからいま、「現場が叩けるAPIが開いているか」でツールを選ぶのは、将来への投資です。AI前提の経理は、もう始まっています。

このシリーズで言いたかったのは結局これです。AIに任せられる範囲は、AIの賢さではなく、あなたのツールがどれだけ「開いているか」で決まります。

参考（公開情報）

• freee: Public API（利用条件） ／ 会計APIリファレンス
• マネーフォワード: クラウド会計APIについて ／ 従量課金・オプション料金
• NetSuite: Concurrency Governance Limits（Oracle）

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

1. 「経理はAIに任せられない」の先へ——AI前提の統制を、いま設計する
2. 新規取引先チェックをAIに任せたら、合併で消えた会社を見つけてきた
3. 経費精算のレシートと明細を、AIに全部突合させてみた（この記事）
4. AI前提の経理は、会計ソフトを「APIが開いているか」で選ぶ

たび

ミソは「全部AIに読ませない」こと。テキストが取れるレシートは機械が一瞬で突合、画像だけAI（Claude）が読む。速いし安いです。

何をチェックする作業か

経費精算の明細は1件ごとに、添付レシートと金額・日付・税区分が合っているかを確認します。件数が多く、しかも「税込金額がレシートに本当に載っているか」を一枚ずつ見るのは地味に消耗します。ここを自動化しました。

AIに任せた流れ

まずバクラクから申請と明細、レシート実体を取ってきます（ここはベンダーAPIなので擬似コード）。

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

レシートからテキストを抽出します。PDFならテキスト層が取れます。

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

ここが今回のキモです。テキストが取れた分は上の機械処理で一瞬。取れない画像／スキャンのレシートだけ「要OCR」に振り分けて、そこをAI（Claude）が画像として読みます。

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

やってみたら、こういうのを拾った

実際に回すと、目視だと滑りやすいものが引っかかりました（いずれも内容は伏せます）。

• 分割計上：1枚のレシート（合計が大きめ）が複数の明細に割られていて、各明細の金額がレシートのどこにも出てこない→自動で「金額不一致」
• 税率の混在：明細は課税10%なのに、レシート側に軽減8%や対象外が混ざっている→「要確認」
• 適格請求書じゃない証憑：予約確認書・フリマの取引画面など、登録番号（T＋13桁）が無いもの→種別を判定して注意フラグ

どこまで任せて、どこは自分がやるか

機械とAIに任せたのは「全明細を突合して、要確認を上げてくる」ところまで。承認・差し戻しは自分です。

おまけ：このコードも全部AIに書かせた

前回と同じく、ここに載せたコードは自分でゴリゴリ書いていません。「レシートと明細の何を照合したいか」をAIに渡して、実装はAI、レビューと検証は自分。経費精算と支払申請で共通する処理は、AIに共通ヘルパーへ切り出させて使い回しています。

シリーズ最終回は、ここまでの実践で見えた「ツール選びの結論」です。→ AI前提の経理は、会計ソフトを「APIが開いているか」で選ぶ

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

1. 「経理はAIに任せられない」の先へ——AI前提の統制を、いま設計する
2. 新規取引先チェックをAIに任せたら、合併で消えた会社を見つけてきた（この記事）
3. 経費精算のレシートと明細を、AIに全部突合させてみた
4. AI前提の経理は、会計ソフトを「APIが開いているか」で選ぶ

たび

丸投げで放置、じゃありません。AIに担当させて、自分は最後の判断だけやる。やってみたら想像以上に実用でした。

そもそも、何を確認する作業か

新規取引先の登録申請が来るたび、確認するのはこの4点——実在するか／商号は正しいか／インボイス登録番号は整合するか／法人番号は妥当か。単純ですが件数があり、合併で閉鎖された番号のような落とし穴は目視だと普通に見逃します。

AIに「チェック担当」として渡してみた

やったことはシンプルです。AIに申請とツール（API）を渡して、こう動かします。まずバクラク側から対象の申請を取ってきます（ここはベンダーのAPIなので擬似コード）。

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

次が本題です。法人番号は「それっぽい13桁」でも、チェックディジットで真偽が分かります。ここは国が公開している計算式なので、実コードを載せます。

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に当てます。AIが数字を捏造する余地がないのは、ここで一次情報に照合しているからです。

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」と「要確認」に振り分けます。人が見るのは要確認だけです。

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"

やってみたら、消えた会社を拾ってきた

実際に回したら、ある申請の法人番号が合併ですでに閉鎖済みのものでした。存続する会社は別の番号を持っています。名前は合っているので目視なら通しかねないところを、閉鎖年月日と承継先番号を見て自動で「要確認」に落としました。差し戻したのは自分です。

APIキーが無くても、AIがWebで代替照合する

実はこのチェック、国税庁の公式Web-APIには無料のアプリIDが要ります。発行が間に合わないこともあります。でも止まりません。APIが使えないときは、AIに法人番号データベース（houjin.info など）で一件ずつ実在・商号・閉鎖を調べさせます。やることは人間の手作業と同じです——番号で引いて、登記の商号と申請名を見比べ、閉鎖していないか確認する。

しかもこの手順はプロジェクトのREADMEに書いてあって、AIはそれを読んでそのまま実行します。人に手順書を渡して仕事を任せるのと同じです。要点はこれだけです。

• houjin.info で登記の商号・所在地・登記状態（現存／閉鎖）・承継先番号を読む
• houjin.jp でもクロスチェック（※旧住所が出ることがある→最新は houjin.info を優先）
• 申請名・住所と照合し、商号不一致／閉鎖／所在地相違なら「要確認」
• 番号はAIが生成しない／参照URLを根拠に残す／承認は人

どこまで任せて、どこは自分がやるか

任せたのは「全件照合して、要確認を上げてくる」ところまで。承認・差し戻しは自分です。

おまけ：このコード、全部AIに書かせた

最後に正直に言うと、ここに載せたコードは自分でゴリゴリ書いていません。要件（何を確認したいか）をAIに渡して、実装はAI、レビューと検証は自分、という分担です。経理がコードを書けなくても、AIを相棒にすればこの手の道具は作れます。

次は「レシートと明細の照合」をAIにやらせた話です（画像をAIに読ませる、より「AIらしい」処理です）。→ 経費精算のレシートと明細を、AIに全部突合させてみた

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

1. AI前提の内部統制を、いま設計する（この記事）
2. 新規取引先チェックをAIに任せたら、合併で消えた会社を見つけてきた
3. 経費精算のレシートと明細を、AIに全部突合させてみた
4. AI前提の経理は、会計ソフトを「APIが開いているか」で選ぶ

たび

論点はもう「AIにできるか」じゃありません。「AI前提の時代に、経理としてどう使うか」を考えられているか、です。

「経理はAIに任せられない」は、本当か

仕訳の確定、申告、承認・統制——「経験と責任があるから人間の仕事」とされてきました。でも分解すると、その大半は「判断」ではなく「作業」です。証憑を読む、科目を当てる、整合性を確かめる、規程と突合する。これらは手順化できます。人にしか残らないのは最終責任と署名であって、作業そのものではありません。まずは、この思い込みを外すところから始まります。

いまのAIは、もう経理の「確定」手前までできる

能力面はすでに足りています。論点を「できる／できない」に置くのは、もう古いです。

• 証憑のOCR＋AIで、勘定科目と税区分を確信度つきで提案する
• 申告書のドラフト生成と、自己チェック（前年比の異常、税区分の不整合、別表の整合性）
• 申請内容を規程・マスタ・過去実績と突合し、根拠つきで承認可否を判定する

論点は「能力」ではない——経理が「渡すために」設計すべきこと

AIの性能より、渡す側の業務設計で結果が決まります。ここが経理の腕の見せどころです。

① 責任と作業を分ける

人が手放せないのは法的な責任と署名です。それは正しい。でも多くの人は、責任と一緒に作業まで抱え込んでいます。仕訳を一件ずつ確定する、申告書を手で組む、申請を目視で承認する——これは作業であって、AIに寄せられます。

② AIに渡せる業務に作り替える（入力を構造化する）

Garbage in, garbage out。AIが賢くなれば解決、ではありません。入口で構造化しておくから任せられます。

• 申請フォームの適正化：自由記述を減らし、選択式・コード化・必須項目化
• マスタと摘要のルール化：取引先・科目の表記ゆれを潰す
• 証憑フォーマットの統一：読み取り前提のデータにする

③ 監査証跡を前提に組む

AIに任せるほど、「なぜそう処理したか」を後から説明できる形が要ります。判断根拠とログを残す設計は、むしろ目視より説明可能性が高いです。

AI前提の内部統制・監査が来る未来を、見据えているか

そして本題です。制度の側がAI前提に変わることを織り込んで、いま業務を作る。ここからは私の見立てです。

• 現状、上場企業の管理部門は生成AI利用に制約が強い。機密の外部送信、承認の人手要件（職務分掌）、監査人がAI出力をどう評価するかが未確立、といった理由で
• 一方、非上場・中小はその制約が緩く、一次処理を自動化して生産性を上げられる
• このまま進めば、上場企業が生産性で不利になる。制度が実務の足を引っ張る構図です
• だから中長期では、監査基準や内部統制の運用がAI前提へ作り替わらざるを得ない——AIによる証跡の容認、継続的監査、AI統制のフレームワーク化へ、と私は見ています

重要なのは結論の当て勘ではありません。「いまは制約があるからやらない」で思考を止めるか、「制度が変わる前提で、AIに渡せる業務設計を先に作っておく」か。この差が、変化の局面で効いてきます。

で、経理として「どうAIを使うか」考えているか

能力はもう足りています。差がつくのは、AIに渡すための業務設計と、AI前提に制度が変わる未来を見据えた準備です。責任は手放さず、作業と前提を作り替える。

あなたは、そこまで考えてAIを使えていますか。

たび

有料テーマに限界を感じて、AIと一緒に自作テーマ「Journal」を作りました。判断の流れと数字を、再現できる粒度で残します。

結果は明確です。スマホの表示速度は約3倍、PageSpeedは96点。ついでにプラグインも18個から6個に整理しました。何をどう判断して進めたかを記録します。

有料テーマに感じていた限界

不満だらけだったわけではありません。むしろ高機能でした。ただ、使い込むほど引っかかる点が増えていきました。

• 設定項目が多すぎて、全部は覚えきれない。多機能ゆえに、どこで何を変えるのか把握しきれない
• 思ったとおりのデザインにできない。用意された枠内での調整になり、細部で妥協が出る
• 決定的だったのは、有料テーマを使っていてもPageSpeed Insightsのスコアが低かったこと

多機能の代償として重さを抱え、カスタマイズも頭打ち。「これ、自分の要件に合わせて作り直したほうが早いのでは？」と考えるようになりました。

「AIに作らせた方が早くないか？」

コードは趣味で書きますが、テーマをフルスクラッチで組むのは個人だと時間が足りない。そこで対話型AIと役割を分けました。

• 要件定義・設計・優先順位 → 自分
• 実装のたたき台 → AI
• レビューと本番反映の判断 → 自分

「こう動かしたい」を具体的に渡すほど、返ってくる実装の精度は上がります。曖昧な指示は曖昧な結果になる——仕様を詰める経理の仕事と本質は同じでした。

実際に入れた改善（ざっくり中身）

「自作」と言っても、奇抜なものを作ったわけではありません。ブログに必要な定番機能を、軽く・自分の要件に合わせて積んだ、という内容です。

• テーマに内蔵した機能：ダークモード／追従する自動目次／コードのシンタックスハイライト／シェアボタン・関連記事／会話吹き出し・ボックス・マーカーなどの装飾／SEO（OGP・構造化データ）
• プラグインをテーマに巻き取り：目次・コードハイライト・問い合わせフォームなどを自前実装し、プラグインを18個→6個に削減
• 速度のための具体策：重いコードハイライト用JS（約120KB）を軽量なものへ置き換え／一覧のサムネ画像を適正サイズで配信／不要なJavaScriptを削減
• データベースも最新化：MySQL 5.7 → MariaDB 10.5 へ移行

つまずいた点と、その対処

たび

丸投げで完成、とはいきません。本番反映と最終判断は、こちら側の仕事です。

実際、記事カードのリンクがHTMLの入れ子で壊れ、本文が出ない不具合も出ました。原因を切り分け、構造を直して解消。検証と修正の積み重ねが品質を決めます。

そして一番ハマったのが、モバイルだけ表示速度が激落ちした件です。原因はGoogle AdSenseの自動広告（Auto Ads）。長い記事ページで広告枠を差し込む処理が重く、本文の描画を2秒以上も遅らせていました。Auto Adsを外したら、一気に改善しました。

結果（実測）

AIは「個人のリソースの壁」を壊す

今回いちばん実感したのはこれです。テーマの自作も、プラグインの全面見直しも、やればできるが、個人の時間では現実的でなかった作業でした。それがAIと組むことで、現実的なコストで実行できるようになった。

裏を返せば、これからは「どうAIを使うか」が、エンジニアかどうかに関係なく効いてくるということ。本業が経理でも、AIを道具として使いこなせれば、できることの範囲は一気に広がります。

作った新テーマ「Journal」は公開します

今回作った新テーマ「Journal」は、公開する予定です。「有料テーマが重い・カスタマイズしきれない」と感じている人がいれば、よかったら使ってください（配布の詳細は追って告知します）。

経理×AIの実践は、こちらの連載で具体的に書いています。→ 連載「経理をAIに任せる」（全4回）

このブログ「経理のAI仕訳帳」では、経理×AIの業務改善・個人開発・お金（投資／副業）の実験を、再現性のある形で記録していきます。