サービス
サービスを探す
プロ人材を探す
仕事を探す
ブログを探す
.png)
Claude Codeを社内導入したのに誰も使わない｜非エンジニアが止まる5つの壁
記事IT・テクノロジー
Claude Codeを入れた。
説明会もやった。
翌週、使っているのは導入した本人だけだった。
これ、珍しくありません。
ツールが悪いわけでも、社員のITリテラシーが低いわけでもないです。
「使い始めるまでに必要な判断」を、全部利用者へ渡しているから止まります。
Claude Codeは、指示した内容をもとにファイルを読み、コードを書き、修正し、コマンドも実行できます。
できることは多いです。
だからこそ、非エンジニアから見ると最初の一歩が分かりません。
どのフォルダで開くのか。
何を渡してよいのか。
実行して大丈夫なのか。
壊れたら戻せるのか。
完成したかどうかを誰が判断するのか。
この5つが曖昧なまま「自由に使ってください」と言われても、普通は触れません。
自由すぎる公園に遊具が1個もない感じです。
はい。立っているしかありません。
私は、Claude CodeやCursorで途中まで作られたツールの引き継ぎ、既存システムの修正、最新版Excelとの計算差分整理などを扱っています。
そこで感じるのは、導入が止まる原因はプロンプトの上手さではないということです。
今回は、非エンジニアが止まる5つの壁と、社内で使われる状態まで持っていく方法をまとめます。
■ インストール後に始まる環境の壁
最初の壁は、Claude Codeを入れることではありません。
入れたあとです。
ターミナルを開く。
対象フォルダへ移動する。
Claude Codeを起動する。
必要ならGitへ接続する。
権限を確認する。
実行環境を用意する。
エンジニアには日常でも、非エンジニアには全部イベントです。
特に止まりやすいのが、次の部分です。
・今どのフォルダを開いているか分からない
・Node.jsやPythonなどの実行環境が足りない
・権限エラーの意味が分からない
・社内ネットワークで通信が制限される
・GitHubの認証で止まる
・Windowsと本番環境の違いを判断できない
ここで「エラー文をClaude Codeに貼ればいい」と言うのは簡単です。
ただ、貼ってよい情報と、貼らないほうがよい情報の区別も必要です。
社内導入なら、最初に1枚の手順を作ります。
・起動するフォルダ
・最初に実行するコマンド
・触ってよいファイル
・入力してはいけない情報
・エラー時の連絡先
・終了方法
豪華なマニュアルはいりません。
最初の10分を一人で越えられる紙が必要です。
■ 「いい感じに直して」で迷子になる要件の壁
Claude Codeは、曖昧な指示でも何かを作ります。
ここが便利で、ここが怖いです。
「ログイン後の画面を最新版に合わせてください」
この指示だけでも修正は始められます。
でも、最新版とは何か。
画面だけなのか。
計算式も含むのか。
Excelと同じ端数処理が必要なのか。
既存データとの互換性は必要なのか。
決まっていません。
実際の修正では、最新版のExcelを読み、今の実装との差分を先に並べるほうが安全です。
入力項目が変わった。
計算式が変わった。
丸め方が変わった。
表示だけ変わった。
出力帳票も変わった。
これを混ぜて「修正」と呼ぶと、完成条件が消えます。
Claude Codeへ渡す前に、最低でも次の形にします。
・現在の状態
・変更したい状態
・変更しない範囲
・正解の資料
・確認方法
プロンプトを長くする必要はありません。
「sheet2026_round修正版.xlsxを正とし、ログイン後画面の入力項目、計算式、丸め処理の差分を一覧化。確認後に修正する。帳票出力は変更しない」
このくらい具体的なら、作業の境界が見えます。
依頼が曖昧なままClaude Codeだけ賢くしても、迷子が高速で走るだけです。
■ ファイルが増えるほど消える全体像
非エンジニアが自分で小さなツールを作る場合、最初は1ファイルです。
そこに機能を足します。
さらに画面を足します。
設定を足します。
バックアップを足します。
気づけば、似た名前のファイルが増えます。
app_new.py
app_final.py
app_final2.py
app_fix.py
app_fix_latest.py
クッッッソ分かります。
私も「latestは一人まで」と思いながら、他人のことだけは言えません。
ただ、Claude Codeは対象フォルダの情報を読めるからこそ、古いファイルや不要なコピーが多いと判断を誤ります。
社内導入では、フォルダ構成を先に固定します。
・実際に動くソース
・設定ファイル
・データ
・ログ
・テスト
・設計メモ
・退避用バックアップ
そして、Claude Codeへ最初に読ませる説明ファイルを置きます。
そこには、
・このツールの目的
・起動方法
・主要ファイル
・変更禁止箇所
・確認コマンド
・現在の未対応事項
を書きます。
毎回、担当者が口頭で説明しなくても、同じ前提から始められる状態です。
Claude Codeを社内ノウハウの置き場にする前に、Claude Codeが読めるノウハウの置き場を作る必要があります。
■ 動いた画面を完成と呼ぶテストの壁
Claude Codeで修正すると、画面が変わるまでが速いです。
ボタンの位置を直す。
文字化けを直す。
入力欄を広げる。
計算式を変更する。
目に見えるので、完成した気になります。
ただ、業務ツールで怖いのは、画面の裏です。
・保存した値が再表示できるか
・別の利用者でも動くか
・日本時間で保存されるか
・複数データを入れて重複しないか
・エラー後に再実行できるか
・印刷して文字が読めるか
・大量データでも遅くならないか
実際、画面上のボタンが2段になっただけでも利用者は気になります。
印刷したら文字が小さい。
現場名ではなく正式名称が出て分かりづらい。
読み込み中に一部だけ表示されて不安になる。
コードとして正常でも、業務として不合格は普通にあります。
だから、社内で使うなら「テストしてください」ではなく、確認表を作ります。
例としては、
・ログインできる
・3件登録できる
・同じ日付を別アカウントで登録できる
・保存後に再表示できる
・エラー時に画面へ理由が出る
・再起動後に処理を再開できる
・印刷結果が1枚に収まる
このように、利用者が見て判断できる言葉へ落とします。
テストコードも大事です。
ただ、現場の人が確認する業務テストは別に必要です。
■ 担当者が休んだ日に止まる運用の壁
社内導入で最後に止まるのは、技術ではなく運用です。
誰が使うのか。
誰が変更を承認するのか。
誰がエラーを見るのか。
誰が最新版を決めるのか。
誰が退職したら引き継ぐのか。
ここが決まっていないと、Claude Codeを使える一人へ全部集まります。
その人が休む。
修正が止まる。
利用者は怖くて触らない。
結局、元のExcelへ戻る。
はい。AI導入の完成です。元に戻りました。
笑えませんけど、起きます。
対策は、全員をClaude Codeの専門家にすることではありません。
役割を分けます。
・利用者は不具合の状況を記録する
・業務担当者は正しい結果を判断する
・管理者は変更を承認する
・開発担当者は修正とテストを行う
さらに、エラー報告のテンプレートを用意します。
・いつ発生したか
・どの画面か
・何を入力したか
・何を押したか
・期待した結果
・実際の結果
・画面の画像
・再現するか
これだけで、修正する側の初動がかなり変わります。
■ 社内導入に必要なのは高性能なプロンプトではありません
Claude Codeを入れたのに使われないと、プロンプト研修を増やしたくなります。
もちろん、指示の出し方は大事です。
ただ、現場が止まっている場所がGitの認証なら、プロンプト研修では直りません。
正解のExcelが3つあるなら、Claude Codeにも選べません。
完成条件がないなら、修正は永遠に続きます。
必要なのは、次の5つです。
・10分で始められる起動手順
・変更前後が分かる依頼書
・迷わないフォルダ構成
・業務で判断できるテスト表
・担当者不在でも回る役割分担
ここまで揃うと、Claude Codeは一気に使いやすくなります。
逆に、ここがないまま導入人数だけ増やすと、質問窓口の人が燃えます。
あなたは今ここまで読んでますよね？
Claude Codeを社内へ入れたいというより、
本当は「担当者しか直せないツールを減らしたい」のではないでしょうか。
それなら、最初に作るべきものは全社向けの大規模研修ではありません。
1つの小さなツール。
1つの手順。
1つの確認表。
この3つで、最初の成功例を作ることです。
すでにClaude CodeやCursorで途中まで作ったツールでも、ソース、実行手順、正解となるExcelや画面があれば、現状との差分を整理できます。
「どこまでできているか分からない」
「エラーが出てから触れなくなった」
「作った人以外が使えない」
この状態からでも大丈夫です。
まず、今あるものを捨てずに、使える状態へ持っていく順番を整理します。
ご相談はこちら
