ノーコードと Claude Code の使い分け:社内ツールを作る前の3つの基準
結論
- 社内の小さな業務ツールは、「作ったあと誰が直すか」「データがどこにあるか」「どれくらい変わるか」の3つの質問で、ノーコードか、Claude Code(ターミナルで動く AI コーディングエージェント)によるコードかを振り分けます。
- 現場の担当者が直す、または Microsoft 365 や SaaS の中で完結するならノーコード。複数のシステムをまたぐ、例外が多いならコードが向きます。
- 「AI で書けるから全部コード」では、属人化の場所が情シスに移るだけです。現場が触る部分はノーコード、裏の重い処理はコードと分け、迷ったら「1年後に誰が直すか」を先に決めます。
先に答え:3つの質問で振り分ける
この記事は、中小DXラボの記事「ノーコードで作るか、Claude Codeでコードを書くか」に書かれた判断基準を整理したものです。執筆時点(2026年10月)で公開されている内容に基づいており、筆者が自分の判断に使っている基準として紹介されています。
中小DXラボの記事では、AI でコードが書けるようになってから、ノーコードで作るかコードで作るかの迷いはむしろ増えたと書かれています。「AI に頼めば何でもコードで作れる」一方で、作ったあとに困るのは自分たちだからです。
同記事が挙げる質問は、次の3つです。
- 作ったあと、誰が直すか
- データがどこにあるか
- どれくらい変わるか
この3つに対する振り分けの目安は、次のとおりです。
- 現場の担当者が直す → ノーコード
- Microsoft 365 や SaaS の中で完結する → ノーコード
- 複数のシステムをまたぐ、例外が多い → コード(Claude Code)
ここでのノーコードは、Power Automate のように、画面上で処理の流れを組む作り方を指しています。
出典: ノーコードで作るか、Claude Codeでコードを書くか — 社内ツールの作り方を決める3つの基準
基準1:作ったあと、誰が直すか
中小DXラボの記事では、これを一番大事な基準としています。現場の担当者が自分で直すなら、ノーコードが向いているとされます。画面を見れば処理の流れがわかるため、「承認者を変えたい」「通知先を増やしたい」といった小さな変更を、情シスを通さずに済ませられるからです。
一方、情シスが面倒を見る前提なら、コードでも困らないとされています。Claude Code にコードを読ませれば、作った本人がいなくても、どこを直せばよいかを説明してもらえるという考え方です。
逆に、現場に渡すつもりのツールをコードで作ると、ちょっとした変更のたびに情シスへ依頼が来ます。作る速さよりも、直す人の手が届くかで選ぶのがポイントです。社内に配る前に、まず誰が直す体制なのかを決めておくと、道具の選択がぶれにくくなります。
出典: ノーコードで作るか、Claude Codeでコードを書くか — 社内ツールの作り方を決める3つの基準
基準2:データがどこにあるか
Microsoft 365 や SaaS の中で完結するなら、ノーコードが楽だとされています。Power Automate なら、Outlook・Teams・SharePoint などへの接続(コネクタ)がはじめから用意されていて、認証の設定に悩むことがほとんどない、という説明です。
社内のファイルサーバーや、複数のシステムをまたぐ場合は、コードが向いています。たとえば「基幹システムから出した CSV と、Excel の台帳を突き合わせて、差分だけを一覧にする」といった処理は、ノーコードでも組めますが、条件が増えるほど画面が複雑になります。コードなら、変換や突き合わせのルールを細かく書けます。
情シスの方は、対象の業務データがふだん置かれている場所を先に確認すると、この基準で判断しやすくなります。
出典: ノーコードで作るか、Claude Codeでコードを書くか — 社内ツールの作り方を決める3つの基準
基準3:どれくらい変わるか
手順がほぼ固定なら、ノーコードで十分とされています。毎月同じ形のデータを、同じ場所に通知するだけなら、作って終わりにできます。
条件分岐や例外が毎月のように増えるなら、コードを選びます。ノーコードは分岐が増えると、画面上で全体を追いにくくなりがちです。コードなら、変更した箇所と理由を履歴として残せるので、「いつ、なぜこの条件が増えたのか」をあとから確認できます。
変更が多い業務ほど、あとから経緯を追えるかどうかが効いてくる、という整理です。
出典: ノーコードで作るか、Claude Codeでコードを書くか — 社内ツールの作り方を決める3つの基準
やりがちな失敗:「AIで書けるから全部コード」
中小DXラボの記事が特に注意しているのが、「AI でコードが書けるから全部コードで作る」ことです。こうすると、直せるのが情シスだけになり、属人化(特定の人しか直せない状態)の場所が「マクロを書いた人」から「情シス」に移るだけになる、と説明されています。
筆者の場合は、次のように分ける形が、今のところ一番うまくいっているそうです。
- 現場が触る部分(入力フォーム・承認・通知)はノーコード
- 裏の重い処理(集計・突き合わせ・変換)はコード
それでも迷うときは、「1年後に誰が直すか」を先に決めてから選ぶことが勧められています。直す人が決まれば、基準2と3は、その人の得意な道具に合わせて考えられるからです。
読むときの注意
ここで紹介した基準は、あくまで一人の情シスの経験に基づく考え方です。費用、ライセンス、セキュリティ設定、Claude Code の具体的な使い方は、この記事では扱われていません。自社の環境に当てはめるときは、各製品の公式ドキュメントで確認してください。
出典: ノーコードで作るか、Claude Codeでコードを書くか — 社内ツールの作り方を決める3つの基準
試す前に確認したいこと:兼任情シスの振り返りから
中小DXラボの別の記事(兼任情シスの振り返り)では、社内DXのつまずきは、ツールの性能よりも進め方の順番と担当の寄せ方で起きやすかったと書かれています。ノーコードかコードかを決める前後で、次の点が参考になります。
ツールを先に決めない
この記事には、先に製品を決めてあとから業務に当てはめた結果、現場の作業の流れとツールの前提が合わず、入力の手間がかえって増えた例が挙げられています。次にやったこととして、ツールを選ぶ前に「今どんな手順で、誰が、何に困っているか」を現場で聞き、紙1枚に書き出す方法が紹介されています。
作る前と作ったあとの確認項目
同記事の筆者が、新しい仕組みに手をつける前に確認している点は次のとおりです。
- 現場の今の手順を、自分の目で見たか
- 困っているのは誰で、何が減れば成功と言えるか
- 自分がいないときに、最初に誰が何をするか
- 1部署・1業務で試せる大きさになっているか
- どうなったら止めるか、を決めたか
全部を満たしてから始める必要はないものの、抜けている項目を自覚しておくだけで、つまずいたときの立て直しが早くなったとされています。基準1の「誰が直すか」は、この中の「自分がいないときに、最初に誰が何をするか」とも重なります。
また、Claude Code を試すときも、最初は自分の作業だけで使い、社内に広げる前にルールを決める順番にしている、と書かれています。
出典: 中小企業の社内DXでつまずいたパターンと、次にやったこと — 兼任情シスの振り返り
よくある質問
現場に渡すツールをコードで作ると、どんな困りごとが出ますか?
中小DXラボの記事では、ちょっとした変更のたびに情シスへ依頼が来ると説明されています。そのため、作る速さよりも、直す人の手が届くかで選ぶのがポイントとされています。
条件分岐や例外が増える業務は、なぜコードが向くのですか?
ノーコードは分岐が増えると、画面上で全体を追いにくくなりがちだからです。コードなら、変更した箇所と理由を履歴として残せるので、いつ、なぜ条件が増えたのかをあとから確認できると説明されています。
Claude Code を社内に広げるときは、どんな順番で進めればよいですか?
兼任情シスの振り返り記事では、最初は自分の作業だけで使い、社内に広げる前にルールを決める順番にしていると書かれています。広げ方としては、まず1部署・1業務で小さく試し、効果と手間を記録してから次に広げるかを決める方法が紹介されています。ルールの具体的な中身は出典に書かれていないため、公式ドキュメントなどで確認してください。
関連する無料ツール
Claude Code CLAUDE.md テンプレート生成: 用途と守ってほしいことを選ぶと、短い CLAUDE.md のひな形を出力します。最初の数行を決めるときに使えます。
参考(執筆時点)
- ノーコードで作るか、Claude Codeでコードを書くか — 社内ツールの作り方を決める3つの基準(中小DXラボの記事)
- 中小企業の社内DXでつまずいたパターンと、次にやったこと — 兼任情シスの振り返り(中小DXラボの記事)
この記事は、上の出典の内容を中小DXラボが要約・再構成したものです。仕様は変わることがあります。社内で使う・配る前に、公式ドキュメントで最新の情報を確認してください。