書いた人：Coopelのマーケティングを担当しています。このコラムでは、AIをただ「使うもの」だと思っていた人間が「作る側」に近づいていく過程を、自分の言葉で残していくつもりです。同じように、AIを業務ツールとして触り始めたばかりの方の参考になれば嬉しいです。
会社でClaude Teamを導入してしばらく経つのですが、正直、私はずっと「使う側」にとどまっていました。思考の壁打ちをしたり、文章や画像を作ってもらったり、情報収集のツールとしては便利だな、と感じる場面はあっても、それで何かを「作る」という発想までは行きませんでした。
そんな中で、社内のAI勉強会が始まりました。講師役1人に対して生徒5人、毎週1回のClaude Codeトレーニングセッションです。私はそこに、生徒のひとりとして参加することになりました。これは、その初回で私が体感したことの記録です。
【目次】
最初の15分で起きたこと
セッションが始まってまもなく、講師がこともなげにこう言いました。
「これ、おそらく数分でできてしまいます」
その日の課題は、ワークフロービルダーのUIを作ることでした。n8nやMakeのようにノードを線でつないで業務フローを組み立てるアプリケーションです。
お客さまに提案するとき、言葉だけでは伝わりにくいので、実際に触って動く画面を見せられたら強いけれど、同じものをゼロから自分で組もうとしたら、数時間はかかるだろう類のものです。
以下のプロンプトを順に入力していきます。
Step 1 — 静的なキャンバスを作る
「ワークフロービルダーのUIを作って。暗いテーマで、左にノードパレット（トリガー、アクション、AI の3カテゴリ）、中央にキャンバス領域を配置して」
Step 2 — ノードを配置できるようにする
「左パネルのノードをクリックしたらキャンバスに追加されるようにして。ノードはドラッグで移動できるように」
Step 3 — ノード同士を線で繋ぐ
「ノードの右側の出力ポートからドラッグして、別のノードの入力ポートに繋げられるようにして。ベジェ曲線で表示して」
Step 4 — テンプレートを追加
「サイドバーにテンプレートタブを追加して。『日報自動集約』『問合せ自動振分』のプリセットをワンクリックで読み込めるようにして
Step 5 — ワークフローの保存と復元
「ツールバーにJSON出力・JSON読込ボタンを追加して。ワークフローをエクスポート→クリア→インポートで復元できるように」
Step 6 — 実行エンジンを組み込む
「実行ボタンを押したら、トリガーノードから順にBFS順でノードを辿って、各ノードの処理結果をログパネルにリアルタイム表示して。HTTPリクエストノードは実際にfetchでAPIを叩いて、AIノードはClaude APIを呼んで結果を返すようにして」
Step 7 — 仕上げ
「ノードをクリックしたら右パネルに設定フォームを出して。HTTPノードならURL・メソッド、AIノードならプロンプトを編集できるように。設定値が実行時に使われるようにして」
とりあえず講師が用意してくれた指示文を次々にClaudeのチャットに投げていきます。すると、画面の右半分で何かが動き始めました。コードが、私の目で追える速度をはるかに超えたスピードで超えて書かれていきます。読みかけた行はもう画面の上の方に押し上げられ、その下にまた新しい行が生み出されていきます。ぼんやりパソコンの画面を眺めている間に、目の前のキャンバスにそれらしいUIが立ち上がっていったのです。
修正したい箇所があれば引き続きチャットで要望を伝えます。「ライトテーマとダークテーマを切り替えられるようにしたい」「サイドバーのテンプレートタブに○○のプリセットを追加して」といった内容も素早く実装が可能です。
これを作るのにかかった時間は15分程でした。左の設定パネルも、ノード一つ一つの設定項目も、データのインポートやエクスポートの機能もひととおり揃っていました。実行ボタンを押すと、今動いているノードが光ったり、実行ログも排出されます。
ただし、正確に言えば、これは「動いている」のではなく「動いて見える」状態です。「Slack送信」のノードが動いたように見えても、Slackに本物のメッセージが飛ぶわけではありませんし、データがどこかに保存されるわけでもありません。見える画面だけが先に作られた、いわばモックです。
それでもお客さんと話す場でこれくらい動くものが手元にあるかどうかは、想像以上に大きな違いだと思いました。
Artifactsについて少しだけ補足します
ここまで読んで、「そもそも、それは何の上で動いているのか」と気になった方もいるかもしれません。私も気になったので、講師に聞いて状況を整理してみました。
私たちが今回使ったのは、Claudeに搭載されている「Artifacts（アーティファクト）」という機能です。普段のClaudeチャットでは何かを質問すると、文章で答えが返ってきます。Artifactsはその延長にあり、文章とは別に目に見える成果物を返してくれる場所です。私が「ランディングページのワイヤーフレームを作って」とお願いすると、Claudeはコードを書き、出来上がった画面を見せてくれます。
このやり方の良いところは、いくつかあります。まず、特段準備をしなくていいことが挙げられます。ブラウザまたはデスクトップアプリでClaudeを開ければ、それだけで何かを作り始められます。
次に、結果を見るまでがとても早いです。コードを生成して、画面に映すところまで、人が手作業でやれば数時間かかる工程が、ものの数分で終わります。
そして、作ったものは保存されており、あとから開き直すことができます。気に入らなければ、その場で「ここをこう直して」と頼めばよく、大幅に作り直してもかまいません。失敗のコストが、ほとんどゼロに近いのです。
一方で、できないことや向かないこともあります。たとえば、お客さまの本番環境にそのまま納めるような使い方には向きません。バックエンドの処理、つまりデータを保存したり、外部のシステムと本格的に連携したりする部分は、Artifactsの中だけでは作りきれません。私たちが今日作ったワークフロービルダーも、画面の上ではノードがつながり、ボタンが反応していましたが、その裏で本物のデータが動いていたわけではありませんでした。
つまりArtifactsは、何かを最終的に納品するための場所ではなく、「この方向性で合っているか」をすばやく確かめるための場所です。お客さまの話を聞いた直後に、その日のうちに動くイメージを見せることができます。最初の一歩のための道具だと考えれば良いようです。
速さが武器になる時代「見せながら話す」へ
講師はそこでさらに踏み込んだことを言いました。
「中身の実装がまだなくても、UIさえあれば、お客さんに『こういうイメージでしょうか』って持ってけちゃうんですよね」
これは、あとから思い返すと、聞いたとき以上に衝撃が大きかったです。これまでの営業現場では、お客さんから要望を聞いたあと、「一度持ち帰って、デモを作ってからまた来ます」というのが当たり前でした。「次回までに」というやり取りが、何度も挟まります。話が前に進むまでに、数週間かかることも珍しくありません。
ところが、いま目の前で起きたことを考えると、そのプロセスが根本から変わる予感がしました。お客さんが話している横で、その場でUIを作り上げます。会議の中盤でたたき台が動いてる状態にすることができます。完璧でなくていい、見た目だけでもいい、これからは「速く形にできること」自体が、ひとつの判断材料として数えられるようになるのではないかなと思いました。もちろん「丁寧さ」や「完成度」が大切であることに変わりはありません。けれどそれと並んで、お客さまの話に画面の実装が追いつく速さが、ここまで武器になる時代は、これまでなかったように思います。
何度も作り直す前提でまずは形にする
そしてもうひとつ、講師の言葉で印象に残ったものがありました。
「壊れることを恐れずに、ガンガン作ってください」
これまで、ソフトウェア開発の場では、今の状態を壊さないことが原則でした。既存の機能を壊さないで新機能を作る、レビューを受ける、そのままテストをする。そのような慎重さが品質を支えていました。
ところが、AIを使った開発では、その慎重さが少し軽くなります。壊れたら壊れる前の状態に簡単に戻せるし、なんなら作り直せばいいのです。もちろん、何でも自由に書き換えていいわけではなく、消してはいけないコマンドや、勝手にやってほしくない操作は、あらかじめガードレールとして禁止しておきます。その安全装置の上で、あとは思い切り走らせる、というのがコツのようでした。
これは、開発のやり方の話というより、ものを作るときの姿勢の話だと感じました。
伝え方は何通りもある
途中、あるメンバーが少し詰まっていました。プロンプトはみんなと同じなのに、なぜかノードとノードがうまくつながらないようでした。そこで改めて指示を出しますが、「線がうまく繋がりません」と書いても、なかなかノード間の線がうまく直りません。
「Claudeは直接この画面を見ていないんです。コードしか見ていない。だから『どの線が、どこと、どうつながらないのか』を具体的に書いてあげてください」と講師が言い、その通りに書き直してみると、一発で直りました。
これは、私が普段の仕事でやっている要件定義そのものでした。お客さまから「業務をもっと楽にしたい」と相談を受けたとき、私はそれを「どの業務の、どのステップで、何をする作業をなくしたいのか」という形に分解できるようにヒアリングします。
AIは、ある程度こちらの言葉を汲み取って「こういうことですか?」と提案を返してくれることもあります。面白いのは、こちらの伝え方によって答え方も変わる点です。出力形式や条件をきっちり指定して渡せば、その通りの精度で答えてくれますし、論点が曖昧なまま相談したときには、こちらが想像していなかった切り口や視点を返してくることもあります。
ただし今回のように具体的なシステムのUIを作る場合は、解釈や発想の余白を残さず、要件が正しく伝わる要に指示をすることが優先です。そのため、人に頼むときと同じように、何が、どこで、どうなってほしいのかを、こちらが具体的に言葉にする必要がありました。 そう考えてみれば、プロンプトを書くという行為は、まったく新しいスキルというより、自分がこれまで磨いてきた仕事の一部が、別の場所で役に立っていた、という発見に近いものでした。
今回のセッションで持ち帰ったもの
その日、コードを書いたことがない私でも、ひとつのアプリケーション画面が瞬く間に出来上がりました。これは、ちょっとした事件だと思います。ただし、本当に大事だったのは、体感した画面実装のスピードよりも、「何を作りたいか」を言葉にしたらものができるという事実を自分の手で確かめられたということそのものでした。
最初から完璧なものを作る必要はなくて、まず大枠を作ってみて、足りないところや上手くいかなかったところを言葉にして補って、また作る。その繰り返しでAIを使いこなしていくという道が、これまでただ使う側にいた人間にも開かれていることがはっきりとわかりました。
来週もまた勉強会があります。次は何を作ろうか、と考えながら過ごすことになりそうです。