3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【みのるん式】Claude Code仕事術を読んだら、自分のモノレポの答え合わせになりました!

3
Last updated at Posted at 2026-11-01

はじめに

こんにちは。
最近職場でもボソボソ音声入力をしているすずきです。

みのるんさん(@minorun365)の『[みのるん式]ビジネスパーソンのためのClaude Code仕事術』を読み「これは学ぶことが多いぞ!」と思ったため書籍レビュー(?)という名の感想を記事にしています。

実は予約注文が始まってすぐの頃にAmazonで予約していたのですが、届くのを待ちきれず、書店に並んでいたのを見つけてその場でも買っています笑。(9月末に届いたAmazonの分は、会社に(勝手に)寄贈しました笑)

9月中旬から読み始め、少しずつ読み進めていたのですが、なかなかじっくり読む時間が取れず、書評はなんだかんだ今になってしまいました。
先に買った分をざっと読んだ時点の感想はXに軽く書いていたので、本記事で改めてまとめます。

この記事は私がベラベラと音声入力して作成しました(息切れ)。

余談:わたしの作業環境

2026年9月から、社内に閉じた業務、個人のコミュニティ活動(登壇・Qiita)、技術調査の3つをinternalというモノレポにまとめ、Claude Codeに話しかけながら回しています。

internalは「社内・内部」の意味で、お客さまの案件(Amazon Connectのコンタクトセンター構築など)はここに1つも入れていません。社外業務(案件など)はフォルダごと隔離して別に作っています。

ディレクトリ構成は「フォルダ構成はAIが探しやすいように」で紹介しています。

このモノレポの土台は、本書を読む前から作っていたものです。読んでみて「やっぱりモノレポにして良かった」と答え合わせができたので、その話を中心に紹介します。

本の紹介

  • 書名: [みのるん式]ビジネスパーソンのためのClaude Code仕事術
  • 著者: 御田稔(みのるん)
  • 出版社: 技術評論社
  • 発売日: 2026年9月24日
  • A5判 / 296ページ

目次は次のとおりです(技術評論社の書籍ページより)。

章 タイトル
第1章 なぜコーディングエージェントが日常業務に有用なのか
第2章 AIエージェントの基礎知識
第3章 Claude Codeのセットアップと基本操作
第4章 何でもAIに相談する癖をつけよう
第5章 【実践1】資料作成の前工程を任せてみよう
第6章 「半自動化」のサイクルをつくろう
第7章 【実践2】経費精算を半自動化してみよう
第8章 モノレポで「コンテキストの複利」を生かそう
第9章 【実践3】プロジェクト業務を「複利」で加速しよう
第10章 育った仕事場を4つの方向へ広げよう
第11章 企業における「セキュリティの壁」の乗り越え方

精読前の感想

書店で買った本をざっと斜め読みした時点で、Xに次のように書いていました。

#みのるん式
精読前の感想

AIエージェントとは?から始まり
Claude(Claude Code)のセットアップ方法→何ができるかの具体→実践という流れがすごい丁寧に説明されてるので帯にあるとおり「何をAIに任せられるのか分からない!」人を置いていかない(寧ろその層を手厚く拾っている感じがする)

ふだんゴリゴリに触っているエンジニアに限定しているのではなくあくまで「ビジネスパーソン」のための内容
→コーディングだけでなく日常業務のアレコレも効率化するために使えるんだよ?なナレッジが詰まっている✨

実践編ももちろん勉強になったのですが、個人的に1番読んでてためになったのが企業利用時に必ず問題になるセキュリティの話

「使わない」ではなく「企業としてAIを使うためには」にフォーカスしているのがすごく嬉しい☺

改めて書くと、本書は「AIエージェントとは?」から始まり、Claude Codeのセットアップ、何ができるかの具体例、実践という順で進みます。一段ずつ順を追って説明されているので、帯にある「何をAIに任せられるのか分からない!」という人を置いていきません。むしろ、その人たちを手厚く拾っている印象を受けました。

目次を見ても、とっつきやすさが伝わると思います。
第5章・第7章・第9章が【実践1】〜【実践3】になっていて、資料作成の前工程、経費精算、プロジェクト業務と、実際のユースケースに沿って「ここまで半自動化できます」という例を挙げてくれています。

Claude Codeの本というと開発の話を想像しがちですが、本書はエンジニアに縛っていません。IDE(VS Code)を使う例も出てきますが、本書はClaude Codeをデスクトップアプリ(Claude Desktop)から使うことを勧めていて、説明もデスクトップアプリ版が中心です。

ビジネスパーソンがIDEを開いて、CLIからClaude Codeを叩く。そういう使い方を前提にしていないことが、しっかり意識されていると感じました。コードを書くわけではないので、コーダー向けの画面ではなく、もう少し視覚的で見やすいデスクトップアプリから使う。とっつきやすさを、使い始める入口の時点から大事にしているのが良いなと思います。

デスクトップアプリ版なら、作ったものを、アプリの中のブラウザ画面でその場で開いて見せてくれたりもします。こういうところも、デスクトップアプリ版を勧めている理由なのかなと思いました。コーディングをするだけのツールではない、ということがよく伝わってきました。

ユースケースも、登壇資料やメール、経費精算など、エンジニアに閉じない題材が並んでいます。自分の業務に置き換えながら読めたのが良かったです。

ビジネスパーソンに向けているからこそ、前提の説明にも漏れがありません。
第1章〜第3章では、生成AIやAIエージェントとは何か、なぜコーディングエージェントが日常業務で使えるのか、というところから始まります。そこからClaude Codeのアプリの入手、インストールと、使えるようになるまでを大きめのボリュームで扱っています。AIとはじめましての人でも置いていかれず、「なんだか便利そう」と思ったところから使ってみよう、となれる構成です。ここでも、ビジネスパーソン全体に向けた内容というのが伝わってきました。

1. 自分の仕事場(internalモノレポ)

モノレポにした理由

もとは7月ごろに作ったQiita執筆用のリポジトリでした。それを9月中旬に、社内業務・コミュニティ活動・技術調査をまとめるinternalというモノレポに統合しました。

まとめた理由は3つあります。

  • 別々のフォルダで、毎回同じ指示を出していた
    • 同じようなことを、フォルダごとに何度も伝え直すのが大変でした
  • ユーザー設定に書くと、案件のフォルダにも全部かかってしまう
    • 使い回せる定型の設定を、1つのフォルダの中だけで使い回したかった
  • 調査・まとめ・発表の根幹は、どの仕事でも同じだった
    • 技術文書の調査も社内業務の調査もします。どこを重点的に見て、どこでポイントをまとめて、どこを詰めていくか、文章をどう構成するかは、使い回せる部分が多くありました

正直なところ、動機はかなり怠惰です。
「もうちょっとAIに任せられないかな」と思い、深く考えずに1か所にまとめてしまったら、意外とうまくいきました。

フォルダ構成はAIが探しやすいように

最初はフォルダ構成をずっと考えていました。

ただ、1か所にまとめたフォルダの中を探していくのは誰かというと、AI(Claude)です。そう考えると、人が見やすい構成よりも、AIが探しやすく仕事しやすい構成のほうが良いと考えました。なので、フォルダ構成もClaudeに丸投げしました。

いまの構成は次のとおりです。

internal/
├── CLAUDE.md          # リポジトリ全体のルール
├── .claude/
│   ├── skills/        # 各プロジェクトのスキルへのシンボリックリンク
│   └── agents/
├── work/              # 社内に閉じた業務 (お客さまの案件は入れない)
│   └── <プロジェクト>/
└── community/         # アマコネ芸人としての活動・技術調査
    ├── qiita/         # Qiita 記事の執筆環境
    ├── slides/        # 登壇スライドの共通環境
    └── <登壇・検証のプロジェクト>/

work/に置いているのは、社内のコミュニケーション、仕事の立て方、タスクの分解といった、社内に閉じた業務です。

図にすると次のようになります。※案件フォルダはモノレポの外に置いています。

minorun-review-fig1-monorepo.png

いまの規模は次のとおりです(2026年11月1日時点)。

項目 数
プロジェクト 8 (work 3 / community 5)
スキル 18
コミット 約200 (2026年7月10日〜)

スキルの実体はほとんどを各プロジェクトの.claude/skills/に置き、ルートからはシンボリックリンクで参照しています。ルートでClaude Codeを起動しても、プロジェクトのフォルダで起動しても、同じスキルが動きます。

本を読んで答え合わせ

楽をしたい、考えなくていいところは投げてしまおう、という雑な発想で始めたものですが、なぜうまくいったのかは、みのるんさんが本書で言語化してくれていました。本書の紹介文の言葉を借りると、こうして育てていく相手が「使うほど育つ自分専用のAI秘書」です。雑に投げてまとめただけのつもりが、割と正攻法でした。

2. 学び・共感した点

第4章 何でもAIに相談する

いちばん共感したのは、最初から閉じずに、まずAIに頼んでみるという考え方です。

「この業務はまだAIにはできないだろう」というのは、思い込みであることが多いです。LLMは2年前と比べるとだいぶ進化していて、あいまいな判断も、手順どおりの定型作業も、精度が良くなっています。ここはできそう、ここはできなさそう、と先に目星をつけるより、まずAIに頼んでみよう、ということが本書には繰り返し出てきます。
頼み方も難しくありません。「こういうことをやりたいから、できないか」と聞くくらいでいいと書いてありました。

第4章では、フォルダの整備もClaudeに任せる話が出てきます。「今後こういうことをやるから、あなたが使いやすいように整えてください」と頼み、やりとりを記録してもらい、ある程度決まったらテンプレート化する、という流れです。私がフォルダ構成を丸投げしていたのと同じでした。

最初の指示は完璧でなくていい、というのも良かったところです。
生成物もそうですが、1発で完璧なものは狙いません。やりとりの中で「ここが違う」「ここはこうすればいい」「その通りで良い」と返していきます。振り返る時間を作ることでAIを成長させていくものなので、最初から100%を目指さなくていいと書いてくれているのは心強いです。

目的と完成イメージを先に伝える、という話もありました。
手順を設計する前に、やりたいことから相談します。1つの作業をするにしても、どうやるかを考える段階からAIと伴走しましょう、ということです。AIは意図を汲み取ってくれますし、汲み取られなかったところはこちらで直せばいい。「こういうことをやりたいんだけど」と話すところから始められます。

第6章 半自動化

ポイントは、完全自動化を目指さず、まずは半自動化を目指すことです。

人が指示して、AIが検索したり仕事を進めたりします。ただ、確定させなければいけないところ、カロリーの高いところ(Webサイトへのログインやメールの送信など)は、勝手にやられると困ります。最終確認を一回挟みたいところです。

なので、「この指示でメール送信まで済ませておいて」ではなく、状況を入れて骨子を作ってもらい、内容を整えて「こんな感じでどうですか」と出してもらい、最終承認は人がやります。完全自動で進む部分と、最終承認の部分を分けるということです。

minorun-review-fig2-semi-auto.png

セキュリティが絡むものや品質を担保したいものは、人が指示してAIがやり、また人に返す、という半自動の形が合っていると思います。
私のQiitaの執筆環境も、下書きからレビューまではAIが回し、公開だけは自分がコマンドを打ったときにしか動かないようにしています。

第8章 コンテキストの複利

完璧を目指さず、ブラッシュアップし続けて、AIと一緒に成長していく。その最たるものが「コンテキストの複利」で、それが最大限に発揮されるのがモノレポの構成です。

これは自分でも実感しています。
同じような業務が来たときに、「ここでやっていたこれを使おう」「これを応用すればできそうだ」とAIが判断してくれます。応用した結果、うまくいったときも、うまくいかなかったときも振り返ることで、共通の部分をスキルとして抜き出したり、今あるスキルをブラッシュアップしたりできます。

共通化したスキルを直すと、シンボリックリンクで参照しているほかのプロジェクトにもそのまま反映されます。1か所で育てたものが、ほかの仕事にもどんどん伝播していくのが、モノレポにして特に良かったところです。

minorun-review-fig3-compound.png

第10章 仕様駆動開発の考え方で品質を上げる

AIの出力を人間の品質の9割まで引き上げる実践手順として、仕様駆動開発の考え方でアウトプットの品質を高める話が出てきます。特に、仕様駆動開発の例を具体的に挙げてくれているのがありがたかったです。

仕様駆動開発は、もともとは開発、つまりコーディングの話です。それを普段の業務でAIを使うときにも同じ形で当てはめます。目的を固めて、骨子を壁打ちして、書かせてから細かく直させる。仕様を固めてから使っていく、という流れです。

そのうえで、AIに直させきれなかったところや、一部だけ直したいという部分は、AIに頼むよりも、VS CodeなどのIDEでMarkdownを直接開いて直すのも一つの手だと書かれています。全部をAIにやらせようとしないところも、半自動化の考え方とつながっていると感じました。

第11章 セキュリティの壁

Xにも書きましたが、本書は「あなた専用のAI秘書」として個人で使う話だけでは終わりません。

企業でガバナンスを整えて使いたいとなると、個人で使える範疇とは話が変わります。それこそ、案件のように一緒に混ぜてはいけない情報もあります。
そこで本書は、「こういう環境では使えません」で止めずに、企業で使うならどこを調整すべきか、企業で安心して使えるようにするにはどうするか、というところまで書かれています。セキュリティ部門と協力して導入を進める、禁止ではなく安全に使える道を作る、という考え方です。

AIと伴走していく働き方は、今後どんどん広がっていくと思います。だからこそ、「ここではAIは使えない」と諦める前に、ルールやガバナンスを整えたうえでどこなら使えるかを考え、導入の準備をしましょう、という話になっています。セキュリティ部門に判断してもらうために、こちらから説明できるようにしておく、というのもその一つです。

学びになったのは、小さく、安全なところから始めるという進め方です。
最初は書き込みまでやらせず、読み取りから始めます。リスクは少なからずつきもので、0にはできません。なので、リスクに対するリターンを示しつつ、低減策を出してリスクを最小限にします。その低減策も、決定論的な仕組みで抑えながら、「それでも使うべきです」「こういう形なら使えます」と説明していきます。
社内ルールの明文化も、「こういうことが起きたらどうするか」という対策のシナリオを利用者の側から提示し、合意を取るところから進められる、と書かれていました。

ビジネスパーソン向けの本だからこそ、「個人で使えて便利です」で終わらせず、組織・企業として使い、推進していくときに大事になるところまで押さえてくれているのが、すごく親切に感じられました。

3. 使っていて一番実感したこと

ここ2ヶ月で自分が一番感動したのはAIのほうから提案してくれるようになってきたことです。

私のモノレポ(internal)には、振り返りからスキルを進化させるためのスキル(/skill-evolve)も置いています。ただ、そういう仕組みとは別に、やりとりの途中でClaudeのほうから「このやりとりは、internalで管理しているxxx処理にも反映できそうです」「ここでも使えそうです」と提案してくれたことが何度かありました。

この記事を書いている最中にも、図の作り方について「登壇スライドや社内資料の図にも使い回せるので、スキルにまとめられます」と提案してくれました。

本書の第8章でいう「コンテキストの複利」を一番直に感じたのが、こうしたときです。1か所にまとめてあるからこそ、AIがほかのプロジェクトとのつながりに気づけるのだと思います。

さいごに

『[みのるん式]ビジネスパーソンのためのClaude Code仕事術』を、自分のinternalモノレポで答え合わせしてみました。

私は普段、Kiro IDEや、ADE(AIエージェント向けの開発環境)のOrcaからClaude Codeを使うことが多いです。ただ本書を読んで、デスクトップアプリ版のClaudeも使ってみようと思いました。日常業務なら十分回せますし、むしろそちらのほうが見やすそうなので、試してみます。

Claudeとはじめましてのビジネスパーソンなら第1章から順に読めますし、すでにClaude Codeを使っているエンジニアには、自分のやり方との比較や深い学びにつながるかと思います。「すでに個人でがっつり使っているけど会社ではAIの導入がまだ進められていない」という人は、第11章のセキュリティの話だけでも読むことをおすすめします!
皆さんもぜひ、自分専用のAI秘書を育ててみてください!

参考

みのるんさんによる書評のまとめはこちらです。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?