文系社長のClaude Code勉強メモ / Artifactに私の眼は追いつかない！
今回は、自分の会社の勉強会に一生徒として潜り込んでみた話です。
エンジニアではない文系経営者で、
「生成AIとかやんなきゃなぁ」
と日々感じておられる方々向けのコンテンツです。
社内でClaude Teamを入れてしばらく経ちます。
正直に白状すると、私自身が、長らく「使う側」に安住しておりました。
壁打ち相手にしたり、文章を書かせたり、便利だなあと感心はするものの、それで何かを「作る」ところまでは一歩も踏み込めていなかったのです。
えらそうにAIだGlobalだと言っておきながら、これはいかん。
そんな折、社内でAI勉強会が始まりました。
講師1人に生徒5人、毎週1回のClaude Codeトレーニングです。
本来なら私は「やっといて！」と号令をかけて腕を組んでいればいい立場かもしれません。
しかし、それでは何も分かりません。
人に指図された仕事は芯から本気になれない、というのは昔さんざん学んだことですが、逆もまた真なり。
分からないものを分かった顔で語るほど、経営者としてカッコ悪いことはありません。
そこで生徒のひとりとして、いちばん後ろの席に座ってみることにしました。
これは、その初回で私が食らった衝撃の記録です。
最初の15分で、私の目が置いていかれた
セッションが始まってまもなく、講師がこともなげに言い放ちました。
「これ、たぶん数分でできちゃいます」
その日の課題は、ワークフロービルダーのUIを作ること。n8nやMakeのように、ノードを線でつないで業務フローを組み立てる、あのアプリケーションです。お客さまへの提案の場で、言葉だけで説明するより、実際に触って動く画面を見せられたら強い。でも同じものをゼロから自分で組もうとしたら、まあ数時間はかかるだろうという類のシロモノです。
用意された指示文を、順番にClaudeへ投げていきます。
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ノードならプロンプトを編集できるように。設定値が実行時に使われるようにして」
指示を投げるたびに、画面の右半分で何かが猛烈に動き始めます。
コードが、私の目では到底追えない速度で書かれていくのです。
読みかけた行はもう画面の上へ押し流され、その下から次々に新しい行が湧いてくる。
まるで、こっちが景色を眺めている間に、勝手に家が建っていくようなものでした。
ぼんやり画面を眺めているうちに、目の前のキャンバスに、それらしいUIがぬっと立ち上がっていったのです。
直したいところがあれば、そのままチャットで頼めばいい。「ライトテーマとダークテーマを切り替えたい」「テンプレートに○○のプリセットを足して」といった注文も、あっという間に反映されます。
これを作るのにかかった時間は、15分ほど。左の設定パネルも、ノード一つひとつの設定項目も、データのインポート・エクスポートも、ひととおり揃っている。
実行ボタンを押せば、動いているノードが光り、実行ログまで流れます。
ただし、正確に言えばこれは「動いている」のではなく「動いて見える」状態です。
「Slack送信」のノードが動いたように見えても、Slackに本物のメッセージが飛ぶわけではないし、データがどこかに保存されるわけでもない。見える画面だけが先に作られた、いわばモックです。
それでもです。お客さまと話す場に、これくらい動くものが手元にあるかないか。
この差は、想像していたよりずっと大きい!
そもそも、これは何の上で動いているのか
ここまで読んで、「で、それは一体どこで動いてるの？」と気になった方もいるでしょう。私も気になったので、講師をつかまえて整理しました。社長が生徒の特権です。
今回使ったのは、Claudeに載っている「Artifacts（アーティファクト）」という機能です。
普段のClaudeは、質問すると文章で答えを返してきます。
Artifactsはその延長線上にあって、文章とは別に、目に見える成果物を返してくれる場所です。
「ランディングページのワイヤーフレームを作って」と頼めば、Claudeはコードを書き、出来上がった画面をその場で見せてくれる。
この方式の良さは、いくつもあります。まず、準備がいらない。
ブラウザかデスクトップアプリでClaudeを開ければ、それだけで作り始められます。
次に、結果を見るまでがとにかく速い。
人手なら数時間かかる工程が、数分で終わる。そして、作ったものは保存されていて、あとから開き直せる。
気に入らなければ「ここをこう直して」と言えばいいし、丸ごと作り直しても構わない。
失敗のコストが、ほとんどゼロなのです。
一方、向かないこともあります。
お客さまの本番環境にそのまま納める、といった使い方には向きません。
データを保存したり、外部システムと本格的に連携したりする裏側は、Artifactsの中だけでは作りきれない。
今日のワークフロービルダーも、画面の上ではノードがつながりボタンが反応していましたが、その裏で本物のデータが流れていたわけではありませんでした。
つまりArtifactsは、最終的に何かを納品する場所ではなく、「この方向性で合ってますか？」をすばやく確かめる場所です。
お客さまの話を聞いた直後、その日のうちに、動くイメージを見せられる。最初の一歩のための道具、と考えるのが良さそうです。
「持ち帰ります」が消える日
講師はさらに踏み込んできました。
「中身の実装がまだなくても、UIさえあれば『こういうイメージですよね？』ってお客さんに持っていけちゃうんですよ」
これは、あとから思い返すほど効いてくる一言でした。
これまでの営業の現場を思い出してください。お客さまから要望を聞く。
「では一度持ち帰って、デモを作ってまた伺います」。
この「次回までに」というキャッチボールが、何度も挟まる。
話が前に進むまでに、数週間かかることも珍しくありませんでした。
私も昔は、この「持ち帰り」を何百回とやってきた人間です。
ところが、目の前で起きたことを踏まえると、そのプロセスが根本から変わる予感がしました。
お客さまが話している、その横で、その場でUIを立ち上げる。
会議の中盤には、たたき台が動いている。
完璧でなくていい、見た目だけでもいい。
これからは「速く形にできること」そのものが、ひとつの実力として数えられていくのではないか。
もちろん丁寧さや完成度が大事なのは、これからも変わりません。
けれどそれと並んで、お客さまの話に画面の実装が追いつく速さが、ここまで武器になる時代は、私の知る限り一度もありませんでした。
「壊れることを恐れるな、ガンガン作れ」
もうひとつ、印象に残った講師の言葉があります。
「壊れることを恐れずに、ガンガン作ってください」
これまでソフトウェア開発の世界では、「今動いているものを壊さない」が鉄則でした。
既存機能を壊さず新機能を足し、レビューを受け、テストを回す。その慎重さが品質を支えてきた。
ところがAIを使った開発では、その慎重さが少しだけ軽くなります。
壊れたら、壊れる前に簡単に戻せるし、なんなら作り直せばいい。
もちろん何でも自由に書き換えていいわけではなく、消してはいけないコマンドや、勝手にやってほしくない操作は、あらかじめガードレールとして禁じておく。
その安全装置の上で、あとは思い切り走らせる。これがコツのようでした。
これは開発の手法の話というより、ものを作るときの姿勢の話だと感じました。
そしてそれは、会社経営にもそっくりそのまま刺さる話です。
私はキャリアの大半を、壊しては作り直す形で歩いてきた人間です。壊れることを恐れていたら、五反田からGlobalなんて口が裂けても言えません。
伝え方は、何通りもある
途中、あるメンバーが少し詰まっていました。
プロンプトはみんなと同じなのに、なぜかノードとノードがうまくつながらない。
「線がうまく繋がりません」と書いても、いっこうに直らない。
そこで講師が言います。
「Claudeは直接この画面を見ていないんです。コードしか見ていない。
だから『どの線が、どこと、どうつながらないのか』を具体的に書いてあげてください」。
その通りに書き直したら、一発で直りました。
これは、我々が普段お客さまにやっている要件定義、そのものです。
「業務を楽にしたい」という相談を、「どの業務の、どのステップで、何をなくしたいのか」に分解してヒアリングしていく、あの作業です。
面白いのは、こちらの伝え方で、AIの答え方も変わる点です。
出力形式や条件をきっちり指定すれば、その通りの精度で返してくる。
逆に論点が曖昧なまま相談すると、こちらが想像もしなかった切り口を返してくることもある。
ただし今回のように具体的なシステムのUIを作る場合は、解釈の余白を残さず、要件を正しく伝えるのが最優先。
人に頼むときと同じで、何が、どこで、どうなってほしいのかを、こちらが言葉にする必要がありました。
そう考えると、プロンプトを書くというのは、まったく新しいスキルというより、これまで磨いてきた仕事の腕が、別の場所で役に立っていた、という発見に近いものでした。
長年やってきたことは、無駄にならないんですね。ちょっと救われた気持ちにもなりました。
社長が持ち帰ったもの
その日、コードを一行も書いたことのない私でも、アプリの画面が瞬く間に立ち上がりました。これは、ちょっとした事件です。
ただ、本当に大事だったのは、目撃したスピードそのものより、
「何を作りたいか」を言葉にすれば、ものができる
この事実を、自分の手で確かめられたことでした。
最初から完璧を狙わなくていい。
まず大枠を作り、足りないところを言葉で補って、また作る。
その繰り返しでAIを使いこなす道が、これまでただ使う側にいた人間——それも会社のトップ——にも、はっきりと開かれている。
それが分かっただけで、この15分には十分すぎる価値がありました。
来週もまた勉強会があります。次は何を作ってやろうか。
還暦間近でも、まだまだ何かやれそうな気分でワクワクしています！
「何から手をつけるか」を考えるための実践的なヒントを資料に凝縮しました。無料ダウンロードはこちらから
