Claude Codeの使い方｜非エンジニア経営者の最初の一歩と落とし穴

非エンジニアがClaude Codeで会社を回している

プログラミングができない自分にも、Claude Codeは使えるのか——こう考えている経営者や事業責任者は少なくないと思います。

僕の場合、答えは「はい」です。むしろ、プログラミングができないからこそ、Claude Codeの本当の使い方が見えるのだと感じています。

ハンズバリュー株式会社の代表であり、ITコーディネータとして中小企業の経営支援に携わってきました。非エンジニアですが、Claude Codeのおかげで、自社開発プロダクトを19個作りました。そのうち15個は本番稼働中です（2026年7月18日時点）。議事録の整理、メール下書き、タスク登録の自動化、財務分析ツール、Chatwork連携、WordPress監視システム——つまり、ほとんど毎日の業務をAIに任せている状態です。

この記事の約束は、ツールの機能紹介ではなく、「業務で実際にClaude Codeを使うための最初の一歩」と「先に知っておくべき落とし穴」を、実体験に基づいて書き残すことです。

全体像をもっと知りたい方は自社開発プロダクト19個の全体記を、Chatwork連携など個別の実装方法に興味のある方は実装記を、この記事との組み合わせでご活用ください。

「生成AIは使っている。でも業務は変わらない」の正体

多くの企業で、ChatGPTやClaudeなどの生成AIは導入されています。社員が文章作成や資料調べに使い、ブログ記事を書く時間は短くなったかもしれません。

しかし、業務そのものはどうでしょう。実務の流れ、意思決定のスピード、人間にしかできない仕事の範囲——これらは本当に変わったでしょうか。

多くの経営者から「AIは試しているけれど、業務が劇的に変わった実感がない」という声を聞きます。その原因は、実は構造的なものです。

第一に、チャット型のAIは「会話の窓の中」に閉じています。ファイルを勝手に開いたり、保存したり、社内システムに接続したりすることができません。その結果、人間がコピー・ペーストで情報を運搬する羽目になります。これは見た目の時間は短縮できるかもしれませんが、業務を根本的に変えません。

第二に、毎回ゼロから説明が必要です。AIは会話ごとにリセットされるか、あるいは説明を忘れます。会社のルール、業務の文脈、禁止事項、社内用語——こうした前提を毎回教える労力が、実はかなり大きいのです。AIに「議事録を書いて」と言えば自動化できますが、「議事録をこの順番で、この形式で、この項目を必ず入れて書く」というルールを忘れさせてしまったら、また一から説明する羽目になります。

ハンズバリュー社では、社員8名がタスク管理システムを使い、ホームページ制作のクライアント約100社を管理しています。チャット・タスク管理・サイト監視・財務分析など、複数の業務システムが毎日動いています。この複雑さの中で「手がない」「記憶の置き場がない」というAIの限界が、むしろはっきり見えるのです。

Claude Codeが解決するのは、まさにこの二つです。

Claude Codeとは — 「答えるAI」から「作業するAI」へ

Claude CodeはAnthropicが提供するツールです。名前に「Code」とありますが、コード専用ではありません。

見た目は、チャット型のAIに似ています。しかし中身は根本的に異なります。Claude Codeは、AIが自分でファイルを読み書きし、コマンドを実行し、作業を完了させることができます。ターミナルやテキストエディタを開いて、プログラムを書いて、それを実行する。人間がやる一連の操作を、AIが肩代わりするということです。

「Claude Code」という名前に引っ張られて、このツールを「プログラミングを自動化する道具」だと思う人が多いのですが、実際には違います。僕の用途を見ても、議事録の整理、メール下書きの作成、記録の更新、そしてシステム開発——コードを書く作業だけではありません。むしろ、コードを書くのはAIの仕事であって、人間の仕事ではないのです。

非エンジニアにとって、Claude Codeの本当の価値は、「プログラムを書く道具」ではなく「日本語で指示できる実務担当者」を雇うことと同じです。こうして人の指示を受けて自分で手を動かすAIは、一般に「AIエージェント」と呼ばれます。仕様を日本語で伝える。AIがコードを書く。人間が検証し、間違いを見つけ、修正を指示する。このサイクルが回ります。

実例を一つ挙げます。社員から「議事録を処理したら、宿題が自動でタスクに登録される仕組みが欲しい」という要望が上がったことがあります。これは技術的には「MCPサーバー」（AIと業務システムをつなぐ接続プログラム）を自社で実装するという複雑な話です。普通は、外注してコストと時間をかけるか、あきらめるかのどちらかです。ところが、社員の要望を当日中に実装して本番反映できました。

プログラミングの知識がなかったら、このスピードは不可能です。しかし、「やりたいこと」を明確に言葉にすることはできました。その言葉を、Claude Codeが理解し、コードに翻訳し、実行してくれたのです。

最初の一歩 — 指示書ファイル（CLAUDE.md）に会社のルールを書く

では、Claude Codeを導入したら、最初に何をすべきでしょうか。

多くの人は「まず何か作らせてみよう」と考えます。僕の答えは違います。最初の一歩は、コードを書かせることではなく、会社のルールを1つのファイルに書くことです。

Claude Codeには、起動時にCLAUDE.mdという指示書ファイルを読み込む仕組みがあります。名前は難しそうに見えますが、実体はただのテキストファイルです。ここに書いたルールを、AIは起動のたびに読み込み、作業中ずっと守ります。つまり、前のセクションで挙げた「毎回ゼロから説明しなければならない」という問題が、このファイル1つで消えるのです。

たとえるなら、新入社員に業務マニュアルを渡すように、AIに会社の「規程」を預けるということです。

僕の会社では、会社のルール・業務手順・禁止事項をこのCLAUDE.mdに書いて運用しています。たとえば、指示語と手順書の対応表を登録してあります。僕が「議事録を書いて」と言えば、AIは議事録の手順書を先に読んでから作業に入ります。メールを頼めば、宛先の確認ルールに従って下書きを作成します。やってはいけないこと——本番データベースへの直接操作や、確認なしの破壊的コマンド——も、同じファイルに明文化してあります。

マニュアルが整っている会社ほど新人が早く戦力になるように、CLAUDE.mdが充実している会社ほどAIが早く戦力になります。逆に、ルールが曖昧だと、AIは毎回試行錯誤することになり、結局は人間が何度も修正指示をすることになるのです。

そして、この作業に技術力は要りません。要るのは、自社の業務を言葉にする力です。これは、経営者や管理職が日常的にやっていることのはずです。

始め方として、僕は次の順番をおすすめします。

第一段階は、議事録や文書の整理から任せることです。失敗してもやり直しがきく仕事から始めます。この段階では完璧を目指さず、「このくらいの品質でいい」という基準を作ることが大事です。第二段階は、うまくいった手順をCLAUDE.mdに書き足すことです。「この形式で」「この順番で」「この項目は必須」と口頭で直した内容を、その都度ファイルに反映していきます。このプロセスを通じて、AIの実装は徐々に安定していきます。第三段階で、ようやく1つの業務を丸ごと任せます。ここまで来ると、AIは「便利な道具」ではなく「業務の担当者」に変わっています。朝の出社時に報告書が完成していたり、メールの下書きが的確だったり、タスクが自動登録されていたり——これまで手作業だった業務が、確実に実行されるようになるのです。

完璧なルールを最初から作ろうとしないでください。僕の会社のCLAUDE.mdには、開発方針としてこう書いてあります。

実用重視。まず動くものを作り、段階的に改善する

この一文は、AIへの指示であると同時に、Claude Codeとの付き合い方そのものだと考えています。ルールも運用も、まず動かして、直しながら育てる。その繰り返しが、組織とAIの信頼関係を育てるのです。

Claude Codeのある1日 — 朝の報告から夜の引き継ぎまで

ルールを書いて運用すると、実際の1日はどうなるのか。僕の会社の運用を時系列でお見せします。

朝は、AIがチャット未読・約100社のサイト監視・タスク・メール返信を横断で確認して報告します。これは複数の独立したシステムの情報を、1つの報告にまとめる作業です。人間がやれば複数のシステムを行き来する横断確認が、朝の挨拶ひとつで走り出します。Chatworkを開いて未読を確認し、次にサイト監視ツールにアクセスして異常を確かめ、タスク管理システムでやることを一覧化する。この一連の流れが、報告書ひとつに置き換わるのです。僕はその報告を見て、今日どこに時間を使うかを決めるだけです。

日中は、議事録の処理、メール下書きの作成、記録の更新をAIが担当します。僕は面談と意思決定に集中することができます。ここで重要な実装が、2026年4月に完成したMCPサーバーです。タスク管理システムにMCPサーバーを自社実装し、議事録を処理すると宿題が自動でカード化されるようにしました。具体的には、会議の議事録をAIに流すと、AIが議事録を読んで「次回までにAさんが○○を確認する」「予算申請を月末までに出す」といった宿題を抽出し、その内容をタスク管理システムのカードとして自動登録するのです。会議が終わって議事録を流すと、その瞬間にやるべきことがタスクの一覧に並んでいる。この仕組みまで詳しく知りたい方は別の記事で実装方法を書いています。

そして夜。ここが運用の核心です。1日の終わりに、AI自身が引き継ぎ資料を更新します。

この夜の仕事が、なぜ必要なのか。AIの記憶は、セッション（起動）ごとにゼロになるからです。昨日何をして、どの案件がどこまで進んでいるか、AIは翌朝には一切覚えていません。もし記憶が消えたままだと、毎朝「状況説明」から1日が始まることになります。毎朝、僕のほうからAIに「昨日この案件はここまで進んだ」と状況を説明し直す羽目になるのです。これは、AIの利点を完全に打ち消してしまいます。

そこで僕の会社では、現在の状態を1つのファイル（STATE.md）に集約し、毎晩AI自身が更新して翌朝読み込む運用にしています。記憶を、AIの頭の中ではなく、ファイルに置くという設計です。人格に覚えさせるのではなく、書類に記録させるのです。実は、この仕組みの正体は、会社の業務日報や引き継ぎ書と何も変わらないのです。

つまり、この運用全体を支えているのは、指示書（CLAUDE.md）と引き継ぎ書（STATE.md）という2つの文書です。業務マニュアル、引き継ぎ書、日報——皆さんの会社にすでにある文書の文化を、そのままAIに向ければよいのです。自社で作ったプロダクト19個の全体像はこちらの記事にまとめていますが、その土台にあるのは高度なプログラミングではなく、この地道な文書化なのです。

一方で、「その文書化に割く時間がまず取れない」という会社もあるはずです。その場合は、現状の棚卸しから外部の手を借りるのも一つの方法です。

落とし穴 — Claude Codeを業務で使う前に知るべき3つ

ここまで良い話を書いてきましたが、業務で使う前に知っておくべき落とし穴が3つあります。

落とし穴1: AIは自信満々に間違える

間違った数字を、正しい数字とまったく同じ顔で出してきます。文章が流暢で、説得力のある表現で。だからこそ、人間は信じてしまいます。ここで重要なのは、対策を「人間が頑張って見抜く」に置かないことです。人間の注意力は、毎日は続きません。疲れた金曜日に「この数字、本当に正しいかな」と疑い続けることは、現実的ではないのです。対策は、検証の機械化です。

僕の会社では、財務数値の計算はAIの暗算を禁止し、必ずプログラム（Python）で検算する社内ルールにしています。AIに計算そのものをさせるのではなく、AIに計算プログラムを書かせて、その実行結果を使うのです。プログラムの実行結果なら、再現性があります。もう一度走らせれば同じ答えが返ってくるのです。数字の背景も可視化できます。「こういう計算式で、こういう順序で、こう足し算した結果がこの数字です」という履歴が残るので、誰でも検算できます。ブログ記事も同様で、機械チェック14項目と、執筆に関与していない別のAIによる検証の二層で検品しています。実は、いまお読みいただいているこの記事自体も、その工程を通過しているのです。

落とし穴2: 本番データの事故

Claude Codeは、実際にファイルを操作し、コマンドを実行できます。Gitリポジトリ（プログラムの変更履歴の保管庫）を書き換えることもできれば、データベースに直接つなぐこともできます。それは裏を返せば、大事なデータを消したり、お客様に見えている本番システムを壊したりする力も持っているということです。うっかり本番データベースに接続してデータを削除してしまう。お客様のホームページを誤ってオフラインにしてしまう。こうしたリスクは、AIが高性能なほど、実は高まるのです。対策は、禁止事項の明文化です。

僕の会社の社内運用ルールには、本番データベースへの直接操作禁止、確認なしの破壊的コマンド（rm -rf等）実行禁止、といった禁止事項を明文化しています。AIに刃物を持たせるなら、先に「切ってはいけないもの」のリストを渡すのです。禁止事項が文書にあることで、AIは危ない操作の前に確認ステップを挟むようになります。

落とし穴3: 同じ失敗の繰り返し

先ほど書いたとおり、AIには記憶がありません。今日苦労して解決した障害を、明日のセッションでまた踏みます。Pythonで△△というエラーが出たから△△という対応をした——その経験がAIに蓄積されないのです。対策は、エラー対応の知見を文書として蓄積することです。僕の会社では、エラー対応の知見を社内知見ベースに41件蓄積しています（2026年7月20日時点の実測です）。過去に踏んだ障害と、その対応方法を記録し続けているのです。

そして、エラーが起きたら、まずこの知見ベースを検索して報告させるルールにしています。社内運用ルールには、こう書いてあります。

この報告なしに修正を2回以上試行してはならない

つまり、「過去に同じ事例がなかったか調べて報告するまで、闇雲に修正を繰り返すな」という縛りです。人間のチームで言えば、トラブル対応のナレッジ共有と同じことです。先輩が経験した失敗を、チーム全体で記憶する仕組みです。

Claude Code活用の本体は何か

仮に、こうしたルールを一切作らずにClaude Codeを走らせていたら、どうなっていたでしょうか。間違った数字の入った資料がお客様に届いていたかもしれませんし、本番データの誤操作が起きていたかもしれません。Claude Code活用の本体は、AIに仕事をさせることではなく、AIを疑う仕組みを整備することです。検証・禁止事項・知見の三つの層で、AIの働きを守る。ここを飛ばした導入は、便利さより先に事故を連れてきます。

自分で始めるか、できたものを使うか

最後に、読者の分岐に正直に答えます。

自社の業務を言語化できる経営者や担当者がいるなら、Claude Codeの導入は現実的です。文書整理から任せ、うまくいった手順をルールとして蓄積し、業務を丸ごと委任する。この記事で書いた順番で、小さく始めてください。必要なのはプログラミングの勉強ではなく、自社の業務を言葉にする時間です。

一方で、「そこまでの時間は割けない」「まず出来上がったものを使いたい」という会社もあるはずです。それも正しい判断だと思います。僕の会社では、こうした自社開発の顧客向けプロダクト群を接客AIクラウドとして商品化し、ホームページ制作のクライアント約100社を対象に提供しています。自分で作る道と、できたものを使う道。どちらを選ぶべきか迷う場合は、お問い合わせから現状をお聞かせください。AIを業務でどう使うかを、御社の状況に合わせて一緒に整理します。

まとめ — 最初の一歩は「会社のルールを書く」こと

要点は3つです。

第一に、Claude Codeは「答えるAI」ではなく「作業するAI」であり、コード専用ではありません。第二に、最初の一歩は、指示書ファイル（CLAUDE.md）に会社のルールを書くことです。第三に、活用の本体は、検証の機械化・禁止事項の明文化・知見の蓄積という「AIを疑う仕組み」の整備です。

僕はこのやり方で、自社開発プロダクト19個・本番稼働15個（2026年7月18日時点の社内棚卸し実測）まで来ました。出発点は高度な技術ではなく、業務ルールの文書化でした。

次の一歩として、自社で毎回口頭で説明している業務ルールを、1つだけ文書に書き出してみてください。それがそのまま、Claude Codeへの最初の指示書になります。

著者: 島田慶資（ITコーディネータ）