僕はいま、NetSuite上で動く入金消込のアドオンアプリを、Claude Codeを相棒にして作っています。
これがけっこう難しい。というのも、会計まわりのシステムって、普通の業務システムとは違う「重さ」があるんです。画面が動けばOKとか、データが登録できればOKとかじゃない。「誰がいつ何をやったか」が全部記録に残っていて、監査で突っ込まれても答えられる作りになっているか、そこが問われる世界です。
これまでこの手の機能は、設計書を何度もレビューして、内部統制チームに見せて、監査法人に説明して……と、人海戦術で品質を担保してきました。当然ながら、すごいコストがかかります。
そこにClaude Codeです。
先に結論を言ってしまうと、監査品質をAIに丸投げするのは無理です。これは作れば作るほど実感します。でも、AIに頼ることはできる。この2つは両立します。というか、両立させないと意味がない、というのが最近の僕の感覚です。
この記事では、実際に入金消込アプリを作っている中で見えてきたことを、経験ベースで書いていきます。どこでAIに任せられないのか、どこで頼れるのか、Claudeとどんな壁打ちをしているのか。同じような領域で悩んでいる人に、少しでも参考になれば嬉しいです。
入金消込が「普通のアプリ」と違うところ
まず、そもそもの話を少しだけ。
入金消込ってなにやってるかというと、「お客さんから入金があったので、対応する請求書と突き合わせて消し込む」という処理です。シンプルに聞こえますよね。でも実装に入ると、普通のWebアプリを作ってる感覚がぜんぜん通用しません。
1円でもズレちゃいけない。これが地味にキツいです。特にやっかいなのが消費税と、外貨扱いのときの為替差損益。どちらも割り算や小数計算が絡むので、端数処理が必ず発生します。しかも「どこで端数を丸めるか」「どの単位で計算するか」をちゃんと設計しておかないと、画面に表示されている金額と、実際に計上される金額が食い違うという事故が起きます。請求書に書いてある金額と、仕訳に計上された金額が1円違う。経理担当者から見れば、これはもう目も当てられない状況です。日付変換と同じで、こういう数値まわりって「動いた」と「合ってる」の間に距離があるんですよね。
「誰がいつ何をしたか」を全部残さないといけない。これはレコードに createdby とか createddate を持たせれば終わり、ではなくて、取消や修正の履歴も全部残す必要があります。監査法人は容赦なく「このレコードの履歴を見せてください」と言ってきます。
削除してはいけない。間違えた消込を取り消すとき、うっかり物理削除の実装をすると一発アウトです。「取り消した」という記録を新しく残す形じゃないとダメ。これ、普通に「削除ボタン作ってください」って依頼を受けたときの発想と真逆なので、けっこう間違えます。
起票した人と承認する人は別人でなきゃいけない。職務分掌(Segregation of Duties)というやつです。これを実装で担保しようとすると、権限設計・画面フロー・ステータス管理まで全部つながって一貫していないといけません。
途中で落ちても中途半端にしない。複数件を一括更新している最中にエラーで止まったとき、「半分だけ消し込まれた請求書」が残ると、翌朝に経理担当者が泣きます。トランザクション境界をどこで切るか、機能要件には書かれていないけど、外すと致命的です。
こういう観点って、機能一覧のExcelには出てこないんですよね。でも、これを外した実装は、どんなに綺麗なコードでも監査の場で「作り直し」と言われます。入金消込という領域は、「動くコード」と「通るコード」の距離が、普通のアプリより遠いんです。
AIに全部は任せられない、と痛感した瞬間
Claude Codeを使っていて、便利だなあと素直に思う場面はたくさんあります。コードの型を整えてくれるし、テストも書いてくれるし、リファクタも一瞬です。これだけでも十分元は取れてると感じます。
でも、会計まわりの機能を作っていると、「これはAIに判断させちゃダメなやつだ」と分かる瞬間が定期的にやってきます。
一番印象に残っているのはこれです。
ある日、更新件数が多くなるフォーム機能をClaudeに作ってもらっていました。ユーザーがボタンを押すと、裏で複数のレコードを更新していく処理です。Claude Codeは生成中に「いま何を実装しています」と中間報告を出してくれるんですが、その中に「同期処理と非同期処理のディスパッチを実装中です」みたいな一文が流れてきた。あれ?と思いました。僕はそんな指示していない。
いったん生成を止めて「いま何を作ろうとしてる?」と聞いてみたら、登録件数によって同期と非同期を自動で切り替える作りにしようとしていたことが判明しました。件数が少ないときは同期で即座に反映、多いときは非同期バッチで走らせる、というやつです。
技術的には面白いんですよ、これ。NetSuiteのガバナンス上限も意識していて、確かにうまく動けばユーザー体験は良くなる。でも僕は、そのまま生成を中断させました。
なぜかというと、コードが二重化するんです。同期ルートと非同期ルート、両方のパスを保守し続けることになる。テストも両方書かないといけない。監査対応のときに説明する処理フローが2パターンに増える。入金消込みたいな「1円もズレちゃいけない」領域で、処理経路が2つあるというだけでリスクが跳ね上がります。
そもそも、僕は最初から「非同期で作る」と腹を決めていました。件数が少ないときに同期にしたいというニーズも実は無かったんです。でもClaudeは、汎用的に見て「良い設計」を提案してくる。これは悪意でも誤作動でもなくて、Claudeの善意が、この業務では裏目に出たという話です。
結局、「非同期一択でシンプルに作り直してください」と伝えて仕切り直しました。出来上がったコードは地味だけど、保守も説明もしやすい形に落ち着きました。
ここで僕が強調したいのは、気づけたのはClaude Codeだったから、ということです。生成の途中で「いま何をやっているか」を逐一報告してくれるので、意図とズレた方向に進んでいるのが分かる。これがChatGPTやGeminiみたいに「はい、完成しました」とドンと全部出されてしまうタイプのAIだったら、出来上がった二重化コードを見て初めて気づくことになる。そうなると、もう一度最初から作り直してもらうコストが跳ね上がります。
でも、中間報告があるからといって、AIが勝手に正解を選んでくれるわけじゃありません。「あれ?」と気づいて止める役目は、人間側にある。しかも、会計・監査の文脈を持っていないと、「同期・非同期の自動切替」を見ても「お、いい実装じゃん」で見逃してしまうかもしれない。
Claude Codeは頼れる。でも丸投げはできない。 この2つは、まさにこの経験で両立するものだと感じました。頼れるからこそ、人間が気づける余地が生まれる。人間が気づかないと、頼っている意味が無くなる。
似たような話は他にもあります。
- トランザクション境界をどこで切るか。Claudeは「落ちたらロールバックする」という実装はしますが、「どこまでを1つの取引として扱うか」は業務側の都合で決まる。そこを指示しないと、勝手に細かく切られて、途中失敗時に半端な状態が残るリスクが出ます。
- 消込の取消処理。最初に作ってもらったとき、Claudeは普通にレコードを物理削除するコードを書いてきました。いや、そりゃそうだよな、と。「取消=削除」というのは一般的な発想です。でも監査的にはNG。「取消ステータスを立てて、元レコードは残す。さらに取消操作ログを別で記録する」と伝えて作り直しました。
- エラー時のメッセージ。開発者目線だと「エラーコードと英文メッセージで十分」ですが、経理担当者が見る画面では「どの請求書の処理で、何が原因で止まったか、次に何をすればいいか」を日本語で表示しないと現場が回らない。これも指示がないとそこまで気が利きません。
要するに、何を重視すべきか、どこに線を引くかを決めるのは人間の仕事なんです。Claudeはそれが決まっていれば驚くほど精度高く実装してくれますが、逆に言うと、決まっていないと「汎用的に良さそうな方」に流れていきます。そしてその「汎用的に良さそう」が、会計領域では過剰だったり的外れだったりする。
監査品質をAIに丸投げできない、というのはこういう意味です。AIが間違えるわけじゃなくて、業務の文脈がAIに見えていない。そこが丸投げできない理由の正体だと思っています。
それでもClaudeに頼る理由
ここまで「AIに丸投げはできない」という話ばかり書いてきましたが、じゃあ使わない方がいいのかというと、全然そんなことはありません。むしろ逆で、Claudeがいなかったら、このプロジェクトはここまで進んでいないと思います。
一番助かったのは、これです。
顧客からの要件を仕様に落としていく段階で、チームに経験の浅いエンジニアがいました。彼が書いた仕様には、正直なところ設計の矛盾や詰めの甘い部分がそこそこ含まれていました。例えば、画面Aで入力した値が画面Bで反映されない前提になっていたり、特定のステータスのときの挙動が書かれていなかったり、バリデーションが画面ごとにバラバラだったり。
レビュアーとしての僕が全部を拾うには時間が足りない。かといって、このまま実装に入ると後で必ず手戻りが発生します。
そこでClaudeにその仕様書をそのまま読ませて、実装指示プロンプトを作らせる作業をしたんです。そうしたら、Claudeが読みながら「ここに矛盾があります」「この条件のときの挙動が未定義です」「この処理はあっちの仕様と整合していません」と、逐一指摘してきました。しかも「こういう解決案はどうでしょう」という改善提案まで付けてくる。
これはちょっと感動しました。経験豊富なレビュアーが横について、仕様書を一緒に読んでくれている感覚に近い。しかも疲れないし、嫌な顔もしない。経験の浅いエンジニアにとっても、自分で書いた仕様にダメ出しされるのが人間相手じゃなくてAI相手なので、精神的なハードルも低い。
この使い方は、ちょっと発想の転換が必要でした。Claudeを「コードを書くやつ」だと思っていると、この価値に気づきません。僕は今、Claudeを「仕様レビューの一次窓口」として使っています。実装に入る前に、Claudeに仕様を読ませて「おかしいところを全部出してください」と頼む。これだけで、実装フェーズに入ってからの手戻りが激減しました。
他にも「頼ってる」と感じる場面はたくさんあります。
- テストケースの網羅。「この機能で起こりうるエラーパターンを全部洗い出してください」と聞くと、人間が考えると漏らしがちな境界値や異常系を、ずらっと出してくれます。全部採用するかは判断しますが、「抜け漏れがないか」のチェックリストとして破格です。
- 監査観点からの設計レビュー。「この設計で監査対応の際にどんな指摘を受ける可能性がありますか」と聞くと、自分では気づかなかった観点が出てきます。たとえば「操作ログの保管期間は要件に含まれていますか」「管理者権限でのデータ修正の証跡はどう残しますか」とか。こちらの文脈を理解させた上で聞くと、監査人の一次レビューくらいの精度で返してくる印象です。
- ドキュメントの下書き。設計書、テスト仕様書、運用手順書など、監査対応で必要な文書の下書きを書かせられます。ゼロから書くのと、下書きに手を入れるのとでは、疲労感がまったく違います。
こういう使い方をしていて気づいたのは、Claudeは「コードを生成する道具」ではなく「業務理解を持った相棒」として使うほうが価値が大きいということです。コード生成はあくまで副産物で、本当の価値は「壁打ち相手としての思考の解像度」にあるんじゃないかと思っています。
一人で設計していると、どうしても自分の思考の癖や盲点が出ます。そこをClaudeに横から突っついてもらうと、「あ、そこ考えてなかった」が定期的に発生する。これが、少人数で監査品質のシステムを作るうえで、本当に効いています。
実際にClaudeとどう進めているか
ここからは具体的な進め方の話です。Claude Codeを使い始めた頃は手探りでしたが、今は自分なりのやり方がある程度固まってきました。完成形ではないけれど、いま効いているなと感じる部分を書きます。
CLAUDE.mdに書いていること
Claude Codeを使うなら、プロジェクト直下の CLAUDE.md をどう書くかが、成果物の質を大きく左右します。僕のCLAUDE.mdには、だいたい4つの系統の情報を書いています。
1. 開発効率化のための前提情報
フォルダ構成、コーディング規約、共通関数の一覧と使い方。このプロジェクトで何をどこに置くか、どんな命名ルールでファイルを作るか、すでにある共通関数はどれで、新規に似た関数を作らないでほしい、といった情報です。これを書いておくと、Claudeが無秩序にファイルを増やしたり、車輪の再発明をするのをかなり防げます。
2. Claudeがどこまで自動でやるかの線引き
ここが意外と大事です。僕は「コード生成と、CLIを使ったNetSuiteへのデプロイ指示文の作成まではClaudeに任せる。ただし実際の実行は人間がやる」と明記しています。デプロイのように環境を変更する操作を、Claudeが勝手に進めてしまわないようにする線引きです。
会計システムの開発では、うっかり本番に何か投げたら取り返しがつかない場面が普通にあります。「どこまでをAIの責任範囲にするか」を文書で固定しておくことは、丸投げを防ぐ実務的な防波堤になります。
3. 生成時のやらかしポイントの事前回避
生成AIが苦手な領域をあらかじめ書いておく、という使い方です。典型的なのは日付変換。NetSuiteのSuiteScriptでは日付の扱いにクセがあり、生成AIは放っておくとズレたコードを書いてくることがあります。なので「日付変換はこのユーティリティ関数を使うこと。独自実装しないこと」と明記し、正しいコード例も添えています。
他にも、SuiteQLで NOT_EXPOSED 扱いのフィールドを参照しにいって失敗するパターンとか、ガバナンス上限に引っかかりやすい書き方とか、経験則で「これはAIが毎回間違える」と分かってきたポイントを順次追記しています。CLAUDE.mdは自分のハマりポイントの蓄積帳のような性格も持ってきています。
4. デバッグ時に見つけた技術的負債の記録方法
これは少し特殊かもしれません。開発中に「あ、ここはいまは妥協するけど後で直したい」という箇所が必ず出てきます。その記録方法をCLAUDE.mdで決めてあります。どういうコメントタグを使うか、どのファイルにTODOを集約するか、といったルールです。
こうしておくと、後で「技術的負債の一覧を出してください」とClaudeに頼んだとき、ちゃんと全部を拾って整理してくれます。負債管理を属人化させないための仕組みです。
Excelの人間向け仕様を、Claude向け仕様に変換する
もう一つ、機能を作るときのワークフローで気に入っているやり方があります。
顧客とのやり取りで出てくる仕様書って、たいていExcelなんですよね。日本の業務システム開発ではほぼ共通の景色だと思います。画面項目一覧、入力規則、処理ロジックが、セルに散らばって書かれている。あれをそのままClaudeに読ませても、いちおう理解はしてくれますが、精度が安定しません。
なので僕は、機能を実装する前に二段階の変換作業を入れています。
第一段階:ExcelをClaude Code向けのmd仕様書に変換させる
Excelの仕様をClaudeに読み込ませて、「これをClaude Codeが実装指示として読みやすいMarkdown仕様書に整理してください」と依頼します。ここでポイントは、人間が読む仕様書と、AIが読む仕様書は別物だと割り切ることです。
人間向けの仕様書は、背景説明や経緯、画面イメージなど情報が豊富なほど良いですが、AI向けの仕様書は曖昧さが少なく、条件分岐が明示的で、用語が一貫していることが最優先です。これを変換の過程で整える。
この作業自体が、仕様の曖昧さをあぶり出す作業にもなっています。Claudeがmd化する途中で「この条件のときの挙動が書かれていません」「この項目の必須/任意が記載されていません」といった指摘を返してくるので、実装に入る前に仕様側の穴を埋められます。
第二段階:md仕様書から、Claude Code向けの作成指示プロンプトを生成させる
md仕様書ができたら、今度はそれを元にして「Claude Codeに渡す実装指示プロンプト」をClaude自身に書かせます。「この仕様書を実装するために、Claude Codeに対してどんなプロンプトを出せば精度高く実装できますか」と聞くイメージです。
これをやると、実装フェーズに入る前に、どのファイルをどんな順番で作るか、どの共通関数を使うか、テストケースに何を含めるか、が整理されたプロンプトが手に入ります。それをClaude Codeに渡して、実装を進める。
この「仕様→md仕様→実装プロンプト→実装」という流れは、手間はかかりますが、途中で仕様の穴に気づける回数が圧倒的に多くなるのがメリットです。実装が始まってから仕様ミスに気づくと手戻りが大きいですが、この流れだと早い段階で気づける。結果的にトータルの時間は短くなります。
ちょっとしたコツ
進め方の話をもう少し書き足しておきます。
Claude Codeで作業していて効くなと感じているのは、「実装に入る前に、Claudeに計画を立てさせる」ことです。いきなり「この機能を作って」と頼むのではなく、「まず、この機能を実装するための手順を一覧化してください。実装はまだしないでください」と指示する。すると、手順を整理したものを返してくるので、それをレビューしてから「この順番でいきましょう」と進める。
これをやらずに直接実装に突っ込むと、先の同期・非同期切り替えの件みたいに、意図と違う方向で走り始めるリスクが上がります。計画の段階で潰せるものは、計画の段階で潰す。当たり前といえば当たり前ですが、AI相手だとこの「計画を先に」を怠りがちなので、意識的にやっています。
もう一つは、長いセッションを続けすぎないことです。会話が長くなってくると、Claudeの文脈理解が微妙にズレてきたり、初期の指示が薄まってきたりすることがあります。機能単位で区切って、新しいセッションに切り替える。このとき、CLAUDE.mdをちゃんと整備しておくと、新しいセッションでも即座に文脈が揃います。CLAUDE.mdは、セッションをまたいで一貫性を保つための共通記憶という位置づけです。
人海戦術の世界を、崩せるのか
少しだけ、業界構造の話をさせてください。
会計や財務まわりの業務システムって、これまでずっと人海戦術で品質を担保してきた領域なんです。SIerが要件をヒアリングして、設計書を書いて、別チームがレビューして、実装して、テストして、内部統制チームに見せて、監査法人に説明して、修正して、またテストして──というフローが何段にも重なっている。結果として、1つの機能をまともに世に出すのに、数人月から数十人月のコストが普通にかかる。
なぜそんなにかかるかというと、「動くもの」ではなく「監査で通るもの」を作らなければいけないからです。機能は動いているのに、ログの粒度が足りなくて作り直し。権限設計の整合性が取れておらず作り直し。取消処理が物理削除で作り直し。こういう「動くものを通るものに引き上げる」工程が、コストの大半を占めます。
そしてそのコストを払える会社しか、まともな会計システムを持てなかった。中小企業やスタートアップが自前の業務ロジックに合わせた会計周りの仕組みを作ろうとすると、「そこに数千万円かけられますか?」という話になって、結局諦めるか、パッケージに業務を合わせるかの二択になる。これが長く続いてきた景色です。
Claude Codeを相棒にして入金消込アプリを作りながら、最近よく考えていることがあります。この景色、変わるんじゃないかと。
といっても、「AIが全部やってくれる未来」という意味ではまったくありません。ここまで書いてきた通り、AIに丸投げはできない。監査の勘所、業務の文脈、どこに線を引くかの判断は、人間が持っていないといけない。この部分は変わらない、むしろ重要性が上がっている気さえします。
でも、人間が業務の勘所を持っていれば、AIに頼ることで一人で数人分働ける。これは僕の実感です。
仕様のレビューを一次的に引き受けてくれるClaude。テストケースの網羅を数秒で洗い出してくれるClaude。監査観点での設計チェックをしてくれるClaude。ドキュメントの下書きを書いてくれるClaude。実装の途中で中間報告を出してくれるから、意図ズレに早期に気づけるClaude。これを全部、一人の開発者が使いこなせる時代になった。
以前なら、仕様レビュアー、テストケース設計担当、内部統制レビュー担当、ドキュメント担当、と分業で人を張り付けていた役割が、「業務の勘所を持った一人の開発者 + Claude」の組み合わせでかなりの部分をカバーできる。完全に置き換わるとは言いません。最終的な判断や、組織としての承認プロセスは残ります。でも、実作業の厚みで見たときに、人海戦術が必要な面積は確実に小さくなっている。
これが意味することは、シンプルです。これまでコスト的に諦められていた領域に、監査品質のシステムが届くようになる、ということです。中小企業が自社の業務に合わせた会計システムを少人数で持てる。スタートアップが成長に合わせて柔軟に業務ロジックを作り変えられる。一人のエンジニアが、かつての開発チーム一個分に相当する仕事を、しかも監査に耐える品質で出せる。
ただし、そこに到達するための前提があります。業務知識を持った開発者がいること。これが絶対条件です。AIは勝手に業務知識を獲得してはくれない。「この業務では何が重要で、どこまで作り込めば十分で、監査で何を聞かれるか」を知っている人間が、AIとの協業の中心にいる必要がある。
だから、業務知識を持ったエンジニアの価値は、AI時代にむしろ上がると僕は見ています。単純にコードが書ける人、汎用的な設計ができる人の価値は相対的に下がっていく。でも、「監査で通る設計とはどういうものか」「経理の現場では何が起きているか」「会計処理のどこで人は間違えるか」を肌感で知っている人は、AIを使って爆発的に生産性を上げられる。
逆に言えば、この領域で人海戦術を崩したいなら、業務を知る努力から逃げられないということでもあります。AIに任せれば会計システムが作れる、という話ではない。業務を学ぶ、監査の視点を学ぶ、そのうえでAIを相棒にする。この順番は、当面変わらないと思います。
おわりに
入金消込アプリを作りながら、毎日「どこまでAIに任せて、どこから自分が引き取るか」の線引きを、少しずつ引き直しています。1円のズレも許されない領域で、この実験を続けるのは正直しんどい時もあるけれど、面白いなとも思っています。
監査品質をAIに丸投げすることはできない。でも、AIに頼ることはできる。この線引きをどこに引くかが、これからの業務システム開発者の腕の見せどころなんじゃないかと、最近は思っています。
同じような領域で悩んでいる方、Claude Codeをこれから試そうとしている方に、この記事がなにかの参考になれば嬉しいです。何か気づきや違う視点があれば、ぜひ教えてください。
