コラム
2026年7月3日
1回目の勉強会の最後に、講師から宿題が出ました。来週までに、それぞれ自分の興味がある領域で業務アプリを作ってみるというものです。1週間で自分でアプリができるのだろうかと少し心配になりましたが、まずは自分の業務を思い起こし、AIを使って効率化したいものをいくつか書き出してみるところから始めました。今回は2回目の勉強会までに私が取り組んだことや学んだことを中心に書いていきます。
【目次】
大きなDXの前に、まず一つの業務から
「何から手をつけるか」を考えるための実践的なヒントを資料に凝縮しました。
無料ダウンロードはこちら
私の業務の一つにコラム記事の作成があります。テーマやキーワードを選定し、検索意図に合った記事の設計と上位記事の情報収集、構成案作成から記事執筆、品質管理まで、これまでも部分的にはAIを使用しながらではありましたが、1つの記事を作り上げるのに丸1日以上かけていたこともあります。ちょうどそのころ、別のメンバーが Gemini で似たような作業を行い、かなりの時間短縮になっている、という話を聞きました。面白そうだと思い、同じことをClaudeでもできないか試してみることにしました。
何から始めればいいのか分からなかったので、とりあえず自分の頭の中の作業手順を、そのまま言葉にして Claude に渡してみました。「キーワードを選んで、まず検索意図を分析します。次に、上位の記事を集めて、その傾向を分析します。それから見出しや内容を固めて構成案を作り、最後にアウトラインまで作ってほしいです」というような感じで、かなりざっくりとしていたと思います。
返ってきたのは、いきなり完成品ではなく、Claude側からのいくつかの質問でした。まず、「上位の記事はどうやって集めますか?検索エンジンのデータを引いてくるサービスを使いますか?」という確認が入りました。参考にしたGeminiのワークフローでも同じサービスを使っていたので、それをClaudeでも組み込むことにしました。次に、「ワークフローを一気に最後まで走らせる形にしますか?それとも、一つのステップが終わるごとに確認して、良ければ次に進む形にしますか?」と聞かれました。私は毎回確認するのが手間だと感じたので、一気に走らせる形をお願いしました。
こうしてやり取りを重ねるうちに、8つのステップに分かれたワークフローができていきました。最初は Gemini でのやり方をなぞるつもりで取り組み始めましたが、Claude と話しているうちに、自分の要望や細かい調整点も伝えていけるようになりました。私が情報として持ち込んだのは、自分がやっている仕事の手順と、こうしたいという希望だけです。それをどう組み上げるかは Claude が引き受けてくれました。困ったこと、あるとよさそうなことを、そのつど相談しては形にしてもらう、その繰り返しでした。
▼今は以下のようなフォルダ構成で使っています。
(プロジェクトルート)├── 00-keywords-prompt.md |
このワークフローを使ってみてしばらく経ってから、これをウェブ画面のフォームから使えるようにしたり、CLI(コマンドプロンプトやターミナル)から呼び出せるようにしたりと、少しずつ使い方の入口を増やしていきました。ClaudeCode環境がないメンバーにも使ってもらえるようにしたかったのと、単純に同じ仕組みでも使うツールが複数あった方が、いざというとき困らなさそうだと思ったからです。
ウェブ画面版は、HTMLとJavaScriptで簡単な入力フォームを作り、キーワードを入れるとスキルと同じワークフローが裏で動く形にしました。CLI 版のほうは、コマンドプロンプトに Claude Code をインストールして、デスクトップ版と同じスキルファイルをそのまま参照させただけで動いてくれました。同じ仕組みでも、入口を変えるだけで動くというのは、少し不思議な感覚でした。
▼ウェブ版の途中経過。まだまだAIぽい。
▼CLIから起動したところ。順調に動いています。
ただ、いくつも作った中で私自身が結局いちばん使うのは、最初に作ったスキル版でした。私はいくつもタブを開いたり、使っていないアプリを起動しっぱなしにしたりすると落ち着かないので、仕事中常に立ち上げているClaudeデスクトップアプリからスキルを呼ぶ形が、性に合っていました。
実際に使い始めてみて、変化はとても分かりやすかったです。これまでは一本の記事を仕上げるのに丸1日かかっていましたが、このワークフローを通すと、同じ工程が1時間から2時間で済むようになりました。
AI活用、最初の一歩の見つけ方
AIで何か始めたいけれど、どう活かすか迷っている方へ。自社に合った始め方の考え方をご紹介します。
無料で資料をダウンロードする
私のほかに参加していたメンバーも個性的なツール作成を試みていました。あるメンバーはMac用のZIP圧縮アプリ、あるメンバーはエンジニア向けの品質保証情報を集約するダッシュボード など、各自思い思いのツール作成に取り組んでいました。
Mac用のZIP圧縮アプリは、MacでZIPを作ってWindowsのデバイスで解凍すると、ファイル名が文字化けしたり、.DS_Store や __MACOSX といった不要なファイルが混入したりするのを防ぐ設定が入ったアプリです。ファイルを画面上にドラッグし、ZIP化するボタンをクリックすると、Windowsで解凍した際にも文字化けしない形でZIPに圧縮してくれて、Mac特有の隠しファイルも自動で除いてくれます。
エンジニア向けの品質保証情報を集約するダッシュボードは、テスト自動化や品質保証に関する記事や情報を、自動で取り込んで一覧で読めるようにするツールです。あちこちのサイトを巡回して情報を集める作業を、一つの画面にまとめてしまおうという発想でした。 こういった情報集約系ツールは既存のサービスにもたくさんありますが、自分の業務に合わせて中身も見せ方も自由に決められるのが、自分で作ることの強みだと感じました。
この勉強会も2回目となり、「どんなことができるのか」という視点も忘れずに持っておきたいですが、私がこのとき知りたかったことは、アプリの出来栄えよりむしろClaudeとのやり取りの進め方の方だと気づきました。そう考えたきっかけとしては、発表を聞く中で、AIを用いた開発の進め方には二つのタイプがあるように見えた、という点が大きいように思えます。
ひとつは、目的とやりたいことをClaudeに伝えて、そのままどんどん実装を任せていくタイプです。何を解決したいのか、誰が使うのか、どんな見た目で動いてほしいのか。そこまでを言葉にしたら、あとはAIを走らせてみます。走らせながら、想像と違うものが出てきたら「ここはこう変えて」と直していきます。前進が速く、手戻りは覚悟の上、というやり方でした。
もうひとつは、できそうなことを最初に洗い出して、これは実現できると確信してから本格的に実装を任せていくタイプです。いきなり全体を作らせるのではなく、小さく試したり、構成を相談したりして、見通しを立ててから実装に進みます。前進はやや慎重ですが、走り出してから止まる回数は少なくて済みます。いわば考えるのが先か、行動するのが先か、という観点にもなりますが、どちらの進め方も面白くて、それぞれどうやって進めていったのか、機会があればプロンプトを見せてもらいたいと思いました。
メンバー全員の今週の発表が終わったあと、講師がこう言いました。
「これは、理解と思考の分離です」
理解と思考、それぞれの言葉は知っているし、なんなら近い意味の言葉だと思っていたので、それらを「分離する」という表現には最初あまりピンと来ていませんでした。
よくよく聞くと、講師が言いたかったこととしては以下のような内容でした。AI開発でコードの一行一行、ライブラリの仕様、設定ファイルの細かい意味すべて理解しようとすると、いつまでも前に進めません。けれど、何も理解せずにAIに任せきりにすると、出来上がったものが本当に正しいのか、後で問題が起きたときに何が原因なのか、判断できなくなります。その中間に線を引く。自分が判断するために理解しておくべきところは、しっかり時間をかけて掘り下げる。それ以外の、任せても問題ないところは、Claudeに任せる。そして、自分が理解した範囲で、ビジネス上の判断や設計の判断を下していく。それが「理解と思考の分離」だ、というお話でした。
なるほど、と少しは納得できた一方で、私は少し疑問に思う点がありました。というのも、世の中の開発者の発信を見ていると、むしろ逆の主張のほうをよく見かけるからです。「AIが書いたコードもちゃんと理解しないと、後で修正できなくなる」「AI任せにしていると自分のスキルが伸びない」といった趣旨の警告です。実際、その通りだとも思います。おそらく、講師の主張は「何も理解しなくていい」という話ではなく、「全部理解しようとしなくていい」という話でした。
そこで、アプリケーション開発ではなく、自分の仕事に照らし合わせて考えてみると、少ししっくり来はじめました。私はマーケティングの仕事をしていますが、業務のすべてを自分で完全に理解しているわけではありません。広告配信の裏側で何が起きているのか、細かい計算式や仕組みは、必要になったときに関係者に聞きながら進めています。そのぶん、自分が判断すべきところ、たとえばコラムやメールで何を伝えたいか、誰に届けたいか、といった判断には時間をかけています。
AIとの仕事も近い構造だと感じています。全部わかろうとしなくていい、ただし、わかっておくべきところは、これまで以上にしっかり考える必要があります。そう思うと、人間が深く理解しておくべき部分と、そうでない部分の線引きが、少しずつ見えてきた気がします。
一方で、開発したツールをお客さまに使ってもらう段階になれば、コードそのものをきちんと理解できる方に、内容を見てもらう工程も欠かせないと思います。動くというだけで満足せず、セキュリティや性能、保守のしやすさといった観点は、これからも人間が責任をもつ領域でしょう。ここは AI に任せきりにできる場所ではありません。つまり、「全部わかろうとしなくていい」という言葉の裏側には、「わかっておくべきところは、これまで以上に丁寧に考える」という条件がありました。前者だけを切り取ると、AI 任せの楽な話に聞こえてしまいますが、実際は逆です。AIに任せる範囲を広げるほど、自分が判断すべき部分の重みは増していくというバランスの取り方こそが、講師の言う「理解と思考の分離」だったのだと理解しています。「理解と思考の分離」は、開発のテクニックというよりAIと一緒に仕事をするときの心構えとして、私の中に腑に落ちました。
だんだんAIで何かを作る感覚、成果を出すための戦力として使いこなす感覚がわかってきました。この勢いで、別の業務アプリ作成にもチャレンジしていくつもりです。次回は、そのチャレンジの中で出会った気づきを、また少しずつご紹介できればと思います。
AI活用の遠回りを防いで、最短ルートで効率化を支援します
やみくもに始めて手戻りする前に。自社に合った進め方の考え方を、無料資料にまとめました。
無料で資料を見る
