経理（財務会計）の実務を20年やってきた人間が、その業務を軽くするソフトウェアを自分で書いています。
- 上場企業およびそのグループ会社で決算・財務会計を10年。その前は上場準備会社で決算・上場申請実務。
- 一貫したテーマは 「経理業務を仕組みで軽くすること」。自作ツール → 基幹システム構築 → ERP入替 → 電子帳簿保存法対応 → RPA → 現在はAIエージェントの自作、と道具を変えながら同じことをやっています。
- 設計思想は 「AIは案を出すまで、確定は必ず人が行う」。会計データを触る以上、AIの出力をそのまま確定させる作りにはしません。
- 合格条件は「動いた」ではなく 「本番と同じ経路で動いた」。書く数値は実測値だけです。
| 動くもの | ポートフォリオ https://www.ai-l-a-b-o.com/works/ ／ コードは下の公開リポジトリから |
| 主な言語 | Python / TypeScript / Go / Ruby |
| 資格 | 日商簿記検定2級 |
- 業務を分解できる。 要件を業務担当者から聞き出すのではなく、自分が業務担当者として書けます。
- 統制を壊さない自動化を設計できる。 会計では「速い」より「間違いが残らない」が優先されます。承認をどこに置き、AIに任せない一線をどこに引くかを、内部統制の運用側にいた前提で決められます。
- 本番に載せるところまでやる。 ローカルで動いたところで止めず、コンテナ化・IaC・CI・クラウド上での実測まで通します。
| 職場（業種） | 内容 | 削減量 |
|---|---|---|
| IT・広告 | 基幹システム構築・業務プロセス再設計 | 月400時間・年700万円 |
| 機械メーカー | 経費精算SaaS導入・電子帳簿保存法対応・RPA開発 | 年100万円以上・月36時間 |
| 現職 | AIエージェントによる経理業務の自動化 | 月30時間 |
- Microsoft Access で販売管理ソフトを自作 — 手元の業務を自分で自動化するところから始まりました
- 15名体制の基幹システム構築に企画段階から参画 — 会計要件の側から入り、業務プロセスごと作り直しました
- ERP入替（SAP／GLOVIA） — 勘定科目・マスタ・締めの運用を、システム側の制約と突き合わせて設計
- SAP Concur 導入、電子帳簿保存法対応 — 法令要件を業務フローとシステム設定に落とす仕事
- RPA開発 — ルールが固定された定型作業を機械に渡す
- AIエージェント開発（現在） — ルールを固定できない判断（仕訳の推定、文書の読み取り）を Claude Code 等でエージェント化し、業務へ実装
RPA までは「決まった手順を速くする」道具でした。AIで初めて「決まっていない判断に案を出す」ことができるようになった、というのが現在地です。ただし 案を出すまで です。
会計データを扱うツールは、AIの出力を人が承認しない限り確定できない構造にしています。
例：請求書仕訳AI（keiri-ai）では、生成した仕訳の 貸借が一致しなければ確定できない制御 を実装しています。「AIが間違えないこと」を前提にせず、「間違いが確定処理を通過できないこと」を実装で担保する、という考え方です。
同じ発想は文書生成側にも入れていて、ai-review-gate ではリスクティアによって自動公開の可否を分岐させ、リスクの高いものは自動では公開されない実装にしています。
ローカルで動いたことは合格条件にしていません。クラウドに載せた状態で同時アクセスや上限判定まで実測して初めて「できた」と書きます。数値は自分で測った値だけを使い、測っていないものは「未確認」と書きます。仮説が実測で否定されたときは撤回します（下の3つ目がその例です）。
| リポジトリ | 内容 |
|---|---|
| kuchikomi-ai-multi-stack | 1つの個人開発サービスを Docker / AWS(Terraform) / GitHub Actions / Ruby on Rails / Go で作り替えた学習リポジトリ。3実装を同一スキーマのまま AWS 上で同時稼働させ、実測値を記録 |
| portable-rag | インストール不可・API不可・オフラインという制約のある業務PC向けのローカルRAG検索。標準ライブラリのみで BM25＋文字bigram＋SQLite転置索引を実装 |
| portfolio | 業務自動化Webアプリ35本 — Flask / Gemini / Anthropic / Notion / Discord |
| keiri-ai | 請求書PDF・写真から仕訳案を生成するAIエージェント（FastAPI / Gemini）。貸借不一致は確定できない制御つき |
| ai-review-gate | AI生成文書のマルチレビュアー品質ゲート。リスクティアで自動公開を制御 |
| self-evolving-ai-public | ツール非依存の自己発展型AI基盤（公開版） |
| MacroPad | 中華製マクロパッド用の設定ソフト（C#） |
同一のサービスを Next.js / Ruby on Rails / Go で実装し、同じスキーマのまま AWS 上で同時に動かしました。実行イメージのサイズは Next.js 202MB に対し Go 17.9MB（ECR上では 5.7MB）。
「Goは軽い」と読んで知っているのと、3つ並べて同じ機能で測るのとでは、その後の技術選定の確度が変わります。
無料利用回数の上限チェックをアプリ側に書くと、同時リクエストで簡単にすり抜けます。そこで判定をDBの関数に移しました。
結果、同時10リクエストを投げても成功はちょうど5件。さらに Go 実装と Rails 実装のどちらから叩いても6回目が 429 で止まることを AWS 上で実測しました。実装言語をまたいでも上限が破れないことを、机上ではなく動いている環境で確認しています。
「制約は、それを守らせたい場所のいちばん内側に置く」という判断です。会計システムで統制をどこに置くかという設計と同じ形をしています。
portable-rag の索引作成が遅く、100件で400秒 かかっていました。最終的に 42秒（9.5倍）まで短縮しましたが、効いたのはアルゴリズムの改善ではなく 作業フォルダがクラウド同期対象だったこと でした。
しかもその前に「索引が育つほど遅くなっているのではないか」という仮説を立てていましたが、指摘を受けて測り直したところ この仮説は誤りだったので撤回しました。説明がきれいに通ることと、それが正しいことは別だ、という一件です。
実際に手を動かして使ったものだけを挙げています。
| 分類 | 使ったもの |
|---|---|
| 言語 | Python / TypeScript / Go / Ruby / C# |
| Web | Flask / FastAPI / Ruby on Rails / Next.js |
| AI | Anthropic API（Claude）/ Google Gemini API / Claude Code によるエージェント開発 |
| インフラ | Docker / AWS（Terraform でIaC化）/ VPS（nginx + gunicorn + systemd） |
| CI・品質 | GitHub Actions / pytest |
| データ | SQLite / SQL（同一スキーマを Rails・Go の両実装で共有） |
| 連携 | Notion API / Discord |
| 業務システム（実務側） | SAP / GLOVIA / SAP Concur / RPA / Microsoft Access |
- 経理・バックオフィス業務のAI自動化（実務を知っている前提で、現場の手順に無理なく差し込む設計）
- LLMの出力を業務で使える形にする設計 — 構造化出力、語彙の制約、要確認フラグ、人間の承認ゲート
- 業務システムとAIの接続（会計・経費精算・文書管理まわりの要件をシステム側の制約と突き合わせる仕事）