非エンジニアほど「仕事が変わる」と実感──Claude Code全社コンテストをプリンシプルで行った話

社内のClaude Codeコンテストで実感度が最も伸びたのは、プログラミング未経験の17名（3.0→3.9）でした。
15チームが1ヶ月走り、土台づくり・チーム戦・集合点の3つが完走の鍵になりました。
業務システム開発の経験者3名だけは4.67→3.33に低下。少人数のため傾向として読んでください。

社内のClaude Codeコンテストで、「仕事が変わる」実感度が大きく伸びたのは、プログラミング経験がまったくない17名でした。

私がCAIOを務めるプリンシプルで開催したコンテストです。

プリンシプルはデジタルマーケティング支援が中心の会社で、参加者の約8割は非エンジニアです。

2026年5月末からの1ヶ月間に15チームが参加し、終了後にアンケートを取りました。5つの定量指標と7つの定性領域に分け、生の声をそのまま拾っています。

そのアンケートを一枚ずつ読み込んで、私自身がいちばん驚いたことがあります。

プログラミング経験がまったくないメンバー17名は、Claude Codeに触れたあと、「仕事が変わる」実感度が5段階で 3.0 → 3.9 に跳ね上がっていました。上昇幅は+0.9で、私が想定していたよりずっと大きな数字です。

一方、業務システム開発の経験がある3名は、4.67 → 3.33。マイナス1.33です。触る前の期待値は飛び抜けて高かったのに、実際に使ってみたら下がっていました。

Claude Codeに最も驚いたのは、エンジニアではありませんでした。 コードを書けないメンバーの体験のほうが、はるかに深く「仕事の再定義」に届いていたのです。

この記事でお伝えするのは、次の3つです。

うまくいった点：未経験のメンバーが何に驚き、何が実感度を押し上げたか
今回の学び：同じことを始める会社への4つの助言
次の一手：「入口」から「文化」へ進むための3つの取り組み

15チーム・1ヶ月・100点満点：こう設計しました

15組のチームが1ヶ月のカレンダーを走り、プロセスに半分を配点した審査を経て、優勝チームが賞杯と食事で祝われる流れを示す図

まずは背景を簡潔に。

対象はPM、広告運用、SEO、解析BI、マーケ・事業開発、事業推進、総務・経理労務、教育・採用と、部門横断の15チームです。

審査は100点のルーブリックで、配点は次のとおりです。

プロセス：50点（全員参加度、ナレッジ共有・役割分担、試行改善ループ、エージェントならではの活用）
業務課題設定・インパクト：20点
成果物：20点
資料：10点

半分をプロセスに振ったのは、1人の英雄に頼ったチームが高得点を出せない設計にしたかったからです。

副賞は、優勝チームのメンバー1人あたり1.5万円までの食事代。金額は大きくありませんが、「チームで祝う仕組み」を入れたかったのです。

最終提出は、対話ログ抜粋、試行サマリ、デモ動画（3分以内）の3点セットです。走り出す前の土台づくりについては、1-4で詳しく書きます。

15チームすべてが、期間内にアウトプットを提出しました。

1. うまくいった点──未経験者の実感度は+0.9、経験者は−1.33

プログラミング未経験者は階段を上るように実感度が上がり、システム開発の経験者は実装リスクに目が向いて実感度が下がる対比を示す図

1-1. 経験が浅いほど伸びて、経験者だけが下がった

まずは定量のサマリです。

実感度は、全体平均でBefore約3.3 → After約3.9（+約0.6）。After「4以上」（「かなり変わる」「仕事の定義そのものが変わる」）の回答は、全体の約7割でした。

月間の業務削減時間は、最大で月80時間。次いで月50時間、月20時間が複数あり、実業務のインパクトとしても十分な数字が並びました。

面白いのはここからです。実感度の変化を「プログラミング経験レベル別」に切り分けると、きれいな逆転現象が現れました。

| 経験レベル | 人数 | Before | After | 変化 |
| — | — | — | — | — |
| レベル1（まったく経験なし） | 17名 | 3.0 | 3.9 | +0.9 |
| レベル2（Excel程度） | 12名 | 3.3 | 3.9 | +0.6 |
| レベル3（スクリプトが書ける） | 3名 | 3.7 | 4.0 | +0.3 |
| レベル4（業務システム開発） | 3名 | 4.67 | 3.33 | -1.33 |

経験が浅いほど上昇幅が大きく、最上位だけが下がる並びです。レベル4は3名なので、あくまで傾向として読んでください。

ここからは私の読みです。経験者はAIが書いたコードの中身が見えるぶん、セキュリティや設計の甘さといった実装リスクに目が向きます。

マイナス1.33は幻滅というより、経験者ほど「本当に怖い実装リスク」を先に見ている数字だと私は受け止めています。

冒頭に「いちばん驚いたのはエンジニアではなかった」を置いたのは、この数字があまりに反直感的だったからです。

1-2. メンバーが驚いた5つの瞬間

では、メンバーはいったい何に驚いたのか。自由回答を読み込んで、5つのパターンに整理しました。

パターンA：AIが逆に質問してきた

> 「何がしたいかも定まっていない時に、自分に質問をして深ぼってくれた」
> 「抽象的な問いに対しても、AI側が質問をして解像度を上げてくれる」

AIが作業者ではなく、壁打ち相手・設計パートナーとして振る舞ったことへの驚きです。こちらの言語化が完成していなくても、AIのほうから問いを立ててくれます。ここが従来のチャット型AIとの決定的な違いでした。

パターンB：エラーを自分で別解に切り替えた

> 「Aのやり方だとうまくいかなかったのでBで動かしますね、とエラーに対してこちらの指示なくとも動いた」
> 「発生したログを貼り付けるだけでバグを発見して直す」

指示待ちのツールから、勝手に判断する存在への飛躍です。エラー原文をそのまま貼るだけの動作が、非エンジニアの武器になりました。

パターンC：ツールをまたいで、手足が動いた

> 「GitHub→Vercelでデプロイなどツールを跨いでも指示一つでやってくれる」
> 「分析だけでなく実際にアクションまでAIで動いてくれる。API連携で選択肢に制限がない」

ChatGPTの延長ではなく、実際に手足が動く存在だと理解された瞬間の驚きです。ここで多くのメンバーが、道具そのものが違うと体感していました。

パターンD：コードが書けてしまった

> 「事前知識がなかったが、チャット感覚でPythonを設計・作成・修正できる。誰でもエンジニアになれる」
> 「3時間以上かけていた作業がボタン1つで完了」

エンジニアと非エンジニアの境目が消えた体感です。「誰でもエンジニアになれる」という一言は、今回のコンテスト全体を象徴していると感じています。

パターンE：隣の人が変わるのを見た（経験者の視点）

> 「自チームで〔メンバー〕らが開発したツールは汎用性も高くすぐに使える。全社で早く使っていけたらと強く思った」

このパターンだけは、システム開発経験のある回答者に偏っていました。経験者は自分の驚きより、周りの人が変わる様子に価値を見ています。

総務チームのリーダーは、パートタイム勤務のメンバーがClaude Codeを入れた直後に「これは仕事の仕方が変わりますね！」と話す様子を見たと書き残しています。

AI導入を誰から始めるか。その答えが、このパターンに隠れている気がしています。

1-3. 仕事の定義は、こう書き換わった

アンケートには、AIエージェント時代における「自分の仕事」の定義が、これまでと何が変わったかを聞く設問を入れました。

多くの回答を読んで気づいたのは、みなが同じ方向を向いているのに、言葉の選び方が5つに分かれることでした。

ひとつ目は、「作業者から設計者・レビュアーへ」。

> 「タスクを実行する→タスクを設計してレビューする」
> 「大半の業務をClaudeが能動的に進行、自身はレビューがメイン」

リーダーの回答にも目立つ言い回しです。自分がAIの上位に立って、業務を整理し直しています。

ふたつ目は、「問いを立てる」への言い換え。

> 「知識を持っていることから、問いを立てられることへ」
> 「今、何が必要か？というゼロイチの課題発見力」

「知識を持っていることから、問いを立てられることへ」は、コンテスト全体でいちばん印象に残った一言です。知っているかではなく、問えるかで価値が決まる。この転換に、多くのメンバーが半歩踏み出していました。

みっつ目は、「AIが同僚・部下になる」。

> 「なくてはならない同僚ができた感覚」
> 「AIエージェントを部下に、確認や修正を加える少し上の立場で見る」

ツールでも部下でもなく、同僚。今のClaude Codeを言い当てる形容として、この言葉を借りたいと思いました。

よっつ目は、「思考量が増える」という反面教師の視点。

> 「思考の量と質が徹底的に増える。業務時間が3〜5倍のイメージ。楽しいけどしんどい」

このメンバーは、削減時間ゼロを申告しつつ、Before/Afterともに5をつけていました。AIで楽になる、という甘い期待とは明確に違う視点です。踏み込むほど思考量は増える。経営として、これは大事な現実だと受け止めています。

いつつ目は、「意識・優先度が変わる」という静かな変化。

> 「頭に浮かぶ発想が実現できる期待値と、形になるスピードが変わった」
> 「面倒なので放置することが減る」

面倒だから放置していた領域が、攻略可能なタスクリストに乗り換わります。この静かな変化は、業務時間の削減以上に組織を変えると私は思っています。

1-4. 走り切れた3つの理由：土台・チーム戦・集合点

振り返ると、うまくいった要因は3つに集約できます。土台を揃えたこと、個人戦にせずチーム戦にしたこと、マイルストーンを区切ったこと。この3つが揃って、全員が同じ方向に走れた1ヶ月になりました。

要因1：最初の土台作り

いちばん効いたのは、走り出す前に「参加ガイド」と「事前インプット」を整えたことです。

ガイドは、AIチームのリーダーが緻密に詰めてくれました。GitHubの運用ルール、機密情報の扱い、提出物のルールまで、開始前に文書化しています。会社として「ここまではやってよい」を先に決めておくと、参加者は毎回悩まずに済みます。AIへの遠慮も、リスクを見落とした暴走も避けられました。

事前インプットは、私のClaude CodeイベントのDay1（基礎編）・Day2（実践編）の動画です。操作方法より、「これまで人が全部やっていた作業のどこをAIに委ね、結果をどうレビューするか」という業務の分解に時間を割きました。

おかげで参加チームは、1週目から「作りたいアプリ」ではなく「変えたい業務」の話ができました。土台を先に整えるかどうかで、AIコンテストの成否は半分決まります。

要因2：個人戦ではなく、チーム戦にしたこと

1人で詰まって諦めるより、複数人で議論しながら1つのAIエージェントを育てるほうが、現実的に前進しました。

上位のチームは、役割分担と統合フェーズの設計が共通していました。ほかにも、あるチームは「予め役割分担を決めることで、最低限自分でやらなければチーム全体が進捗しない構成」を組みました。別のチームは、作業時間が終わるたびに引き継ぎ書をSlackで共有し、担当者が変わるたびにClaudeに整理してもらう運用でした。

具体例を2つ挙げます。

総務・管理系のメンバー3名は、「実装全体」「Slack通知」「案出し・品質管理」の3役割に分けて反復を回し、v14まで作り込みました。広告運用のチームは、混成でOSS開発のような分業を組み、月210時間の削減という試算に到達して、提出物審査で1位になっています。

1人の英雄が全部やる形ではなく、1つのアプリを複数人で少しずつ良くする形が、結果としていちばん強かったです。詰まっても、隣の人が引き取ってくれる。この安心感は、非エンジニア主体のチームに特に効きました。

要因3：マイルストーンを明示的に区切ったこと

キックオフ、事前インプット、中間相談会、提出締切、審査。このリズムを最初に共有して、各チームがどこに合わせて進捗を作ればよいかを迷わないようにしました。

特に効いたのは、6月18日の午後に社内カフェで開いた中間ハンズオンです。私が4時間ほど座り込み、途中の入退室は自由にしました。SlackやDMでは伝えきれない詰まりが、この場で一気に解けました。「あと1歩で動きそうだけど、何を直せばいいかわからない」というチームが、対面で少し話すだけで次の1週間を走れる状態に戻っていきます。

あるチームのリーダーは、アンケートに「動画を自主的に見せるのではなく、一緒に何かをやる時間を録画ではない手法で設ける」と書いてくれました。動画だけでは現場は動きません。「一緒にやる時間」の価値を、参加者側からも言葉にしてもらえた形です。

スケジュールを切る、集合点を作る、対面の時間を用意する。この3つで、1ヶ月のコンテストは「イベントで終わる」から「業務変革の入口になる」に変わります。

2. 今回の学び：これから始める会社への4つの助言

4つの助言を並べた図。社長が旗を掲げて号令をかける、セキュリティ方針をAIに読ませる、動画より対面で集まる、最後の承認ボタンは人が押す

ここからは、同じ取り組みを進めたい推進担当や経営者の方へのアドバイスです。

助言1：まず社長が「やる」と決める

4つのうち、私がいちばん強調したいのがこれです。

技術でも予算でもツール選定でもなく、「社長か責任者クラスが、これはやると決めて号令をかける」こと。他社展開の成功要因として、これがいちばん大きいと私は考えています。

アンケートで「全社展開するとしたら最大のハードルは」と聞くと、件数ではセキュリティ・ガバナンスが最多でした。それでも、いちばん考えさせられたのはマーケティング領域のメンバーのこの回答です。

> 「社内のモチベーションの差。知見の差はそんなにハードルにならない」

逆説的ですが、現場で壁になるのは知識の差ではなく、動機づけの差だということです。多くの推進担当者は、まず勉強会やレベル揃えから入ろうとします。

別のメンバーは、最大のハードルに「強烈に推進する人がいるかどうか」を挙げました。「全員が当事者意識をもって触るか」という声も出ています。全員が当事者意識を持つには、トップダウンの号令が土台になります。現場任せにすると業務優先で後回しになり、勉強会が続いてもツールは日常業務に溶け込みません。

推進者は、AIに詳しい必要はありません。「これは会社の将来に効く」と信じ切って動く役員や部長が1人いれば、社内の空気は変わります。私自身、期間中は「これは会社としてやる」と繰り返し発信し続けました。それが、参加率と当事者意識を支えたと思っています。

助言2：セキュリティは、最初にMDで渡す

あるチームのリーダーは、こう書き残しました。

> 「セキュリティやガバナンスを考えずとりあえずAI導入が一番危険」

具体的な論点も並んでいます。企業秘密情報をどこまでAIに入れてよいか。AIが作った中身を理解できないまま、リスクを見落とさないか。上級者からは、APIキーのハードコーディングといった指摘も出ました。

あるメンバーが残してくれた提案は、そのまま使えます。

> 「セキュリティポリシーをMD化して、スタート時点でAIが参照するところまで管理側が行うべき」

ポリシーは、人が読むPDFやWordではなく、AIが起動時に自動で読むMD形式でルート直下に置く。使えるAPIの一覧と禁止事項をセットで書く。ここまでを管理側が先に整備してから、参加者を走らせるのが順番だと考えています。

助言3：動画より、一緒にやる時間

自主的な取り組みだけに頼らず、「一緒にやる時間」を明示的に確保してください。

対面ハンズオンやカフェ相談会を、月に2〜3回、時間を切って設ける。人数は少なくてかまいません。詰まった人が声を上げて集まれる場があることが大事です。

動画1本に対面ハンズオン2本くらいの重みづけが、現実的なバランスだと思います。

助言4：全自動は目指さない。最後の5%は人が押す

意外と語られませんが、非常に重要です。最初から完全自動化を目指さず、「AIが提案、人がワンクリック承認」の半自動化から入ってください。

アンケートの「詰まったところ」と「突破法」でも、「完全自動化を諦めて現実的な形に転換」が突破法のひとつに挙がりました。Slack自動送信で詰まったチームは、「1ユーザー経由でSlackに送信する」形に切り替えて進めました。別のチームは、Claude Chatとの使い分けを早めに決め、AIが得意な部分と人がやったほうが早い部分を切り分けました。

私は、AI導入が止まる大きな理由のひとつは、完璧に自動化しようとして詰まることだと見ています。95%自動化できるなら、残り5%は人がクリック1回で承認する設計にする。

半自動の設計は、総務や事業推進、解析のチームなど複数のチームで見られました。全自動を目指さないことが、逆説的に、現場への定着を早める近道です。