こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 3 回レポートです。シリーズの背景や全体像については、 前回の大阪・初回レポート をご覧ください。 大阪での 2 日間のイベントに続き、2026 年 4 月 22 日は名古屋にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト古屋 楓から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、 Amazon Quick のデモを交えながらご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: 古屋によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中部を拠点に 270 年以上の歴史を持ちながら、経営・現場の双方から生成 AI 活用に挑戦されている 1 社の事例をご紹介します。 事例紹介：タキヒヨー株式会社様 〜経営と現場、両輪で進める Amazon QuickSight によるデータ活用〜 事例紹介は タキヒヨー株式会社 様です。1751 年（江戸時代の宝暦元年）に名古屋で創業された 270 年以上の歴史を持つ繊維アパレル企業で、テキスタイル事業では愛知県一宮市に自社工場をお持ちで、伝統的な英国式紡績機を生かしたものづくりを行われています。アパレル事業では企画・製造・販売に加え、リテール事業として自社ブランドの展開もされており、東京証券取引所・名古屋証券取引所に上場されている企業です。従業員数は540 名(2026年2月末)、ニューヨークに拠点をお持ちのグローバル企業でもあります。 当日は、経営視点と現場視点の両面から、二つのプロジェクトについてパネルディスカッション形式でお話しいただきました。AWS 小嶋がモデレーターを務め、それぞれのプロジェクトの背景から成果までを伺いました。 業務 KPI ダッシュボード化プロジェクト 一つめのエピソードは、執行役員の平田様が経営の視点で推進された、業務 KPI ダッシュボードプロジェクトについてです。 アパレル業界は職人的・属人的な業務傾向があり、勘や経験に頼りがちな面があります。経営として、売上や利益といった KGI よりもっと粒度の細かい業務 KPI で組織の状態を定量的に把握し、営業活動の改善に繋げたいという思いがプロジェクトの出発点でした。ただ当時は、各組織のデータが Excel に散在し、VBA マクロで集計していたため、処理に時間がかかったりマクロが想定どおり動作しないなどの課題がありました。 この課題に対して、 Amazon QuickSight を導入し、基幹システムや NAS のデータを一元的に可視化・分析できる基盤を構築されました。ただ、導入にあたって一番苦労されたのが「現場のアレルギー反応」だったといいます。それまで各マネージャーが各々のやり方で管理業務を回していたところに、統一のダッシュボードを導入するという施策そのものに対して、「手間が増える」という受け止めから反発があったとのことです。 この壁を乗り越えるために、とにかく使い勝手にこだわってプロジェクトを進められました。便利さを実感してもらうことで理解を得て、利用も促進したいと考え、ドリルダウン機能の設計に特に注力されました。 大きなデータから詳細なデータへと段階的に掘り下げることができ、感覚的な操作で目的のデータにたどり着けるよう設計 しました。「普段の動線そのままで使える」ことで現場の抵抗感を下げることに繋げました。また、 データの欠損を補うためにWeb経由のデータ入力の仕組みも構築 し、ダッシュボードに表示されるデータの信頼性を担保する工夫も行われました。 結果として、URL にアクセスすれば経営データがすぐ確認できる状態になり、 現場のマネージャーが本来の意思決定業務に集中 できる環境が整いつつあるとのことです。今後は、分析の精度向上や、分析から起こしたアクションが業績にどう寄与するかの効果検証をしていきたい、とお話いただけました。 需要予測データのダッシュボード構築プロジェクト マーケティングチーム兼DX 推進チームの山口様が現場の実践者として推進されたプロジェクトです。 山口様ご自身はエンジニアではなく、プログラムを書いたご経験はありませんでした。ただ、「自分たちの手でなんとか活性化させたい」という思いから、需要予測データを Amazon QuickSight で可視化するダッシュボードの内製構築に取り組まれました。既存データには、複数の情報（色・柄・素材など）が一つのカラムにまとめて格納されていたため個別の値で抽出できない（例えば何色が売れているか？といった分析はできない）、需要予測の数値が絶対値のみのため、判断の基準がなくアクションに繋がらない、という二つの課題がありました。 開発にあたって、当初は Generative AI Use Cases （ AWSが提供するチャットベースの生成AIアプリケーション）で SQL を生成させていましたが、開発が難航しました。チャットベースのアプリケーションで、必要なデータ（DBのテーブル情報、全体設計、既存データなど）をAIに与えながら作業をさせようとすると、開発が進むほどコンテキストの制限に達してしまい、その都度新しい会話を立ち上げ直す必要が生じ、作業上の煩雑さを生んでいました。さらに、本来は必要なコンテキストを渡しきれない状況も発生し、そうなるとAIが出力するSQLが本来の目的と異なるものになる、といった問題も発生していました。 このような経緯から、チャットボットベースのアプリケーションに限界を感じられ、コーディングエージェントの Claude Code を Amazon Bedrock 経由で利用する方針に切り替えられました。コーディングエージェントであれば、AI エージェントがユーザー指示に応じて必要なローカルファイルを自律的に参照しにいくため、今まで作成してきたテーブル情報やシステム設計、エラー内容までを AI が自動で把握してくれ、開発効率が大きく向上しました。 データの課題については、既存のデータのETLにも取り組まれました。具体的には、一つのカラムに混在していた色・柄・素材などのデータを色別・素材別・シルエット別などにそれぞれのカラムに分けて対応し、絶対値で表示されていた需要予測値も ◎○△✕評価が動的に表示される仕組みに変更されました。この際、Claude Code を単なるコード生成ツールとしてではなく、 目的を共有し、既存のデータを生かすためにどんな方法がよいかを一緒に探る「頼れる相談相手」として活用 されました。「こういう見せ方はどうか」「この分け方だとデータが崩れないか」── ジェンガのピースを崩さないように一つずつ探していくような試行錯誤を、AI と対話しながら繰り返された とのことです。 結果として、 通常であれば外注で数ヶ月・数百万ほどかかるシステムを、非エンジニアの山口様ご自身が数週間で構築 されました。さらに、データ構造を深掘りしていく過程で、 ベンダー側でブラックボックス化していた課題に気づき、改善提案に繋げられた という副次的な効果もあったとのことです。今後は自社に蓄積された売上・在庫データの取り込みや、 Amazon Quick （Amazon QuickSight が進化して生まれた Agentic AI プラットフォーム）の AI チャット機能の活用も検討されています。 お二人から参加者へのアドバイス 最後に、お二人から参加者へのアドバイスをいただきました。 平田様からは、「 まずは現業務を可視化してデータで見られる体制を整えることが第一歩。完璧を目指すのではなく、経営層が現場に対して『小さく試して失敗から学ぶ』ことを許容し、現場の変革を後押しするスタンスが重要 」というメッセージをいただきました。 山口様からは、「 とにかくデジタル上にデータを蓄積することに注力してほしい。デジタルデータは企業の財産になる 」というメッセージ。同じ分量のデータでも、デジタルかアナログかで将来の資産価値が大きく変わる。仮にデータの中身が多少整理されていなくても、AI を活用すれば非エンジニアでも理想的な形に整形できる。 アナログからデジタルへの移行方法自体も、AI に相談してみてほしい 、とお話しいただきました。 写真: タキヒヨー株式会社 平田様・山口様、AWS 小嶋によるパネルディスカッション 経営と現場の両輪で取り組まれたお話に続いて、こうしたデータ活用の取り組みを伴走支援するパートナー様からのセッションです。 パートナーセッション：クラスメソッド株式会社様 〜生成 AI 活用のためのデータ収集〜 お客様事例のあとには、AWS プレミアティアサービスパートナーである クラスメソッド株式会社 データ事業本部 チームリーダー / プロジェクトマネージャーの三鴨 勇太 様より、「生成 AI 活用のためのデータ収集」と題したセッションをお届けいただきました。名古屋オフィスを拠点に、お客様のデータ基盤構築やデータ戦略支援を担当されている三鴨様から、データドリブン経営を支えるデータ基盤整備の考え方をお話しいただきました。 データ収集がデータドリブン経営と生成 AI 活用の共通の土台であるという点を特に強調しました。ビジネスの加速のためには、企業が持つデータ資産を生成 AI と組み合わせることで差別化につながる。そのために、属人化している情報があればそれらを効率的にデータ化し、収集していく仕組みが重要だと述べられました。 データ基盤整備の進め方としては、企業文化に合わせて、 Needs （需要があるところからデータ基盤整備を進めていく） と Seeds （できるところからデータ基盤整備を始める） の 2 つのアプローチのどちらを取ることもあり、クラスメソッド様が提供するデータ活用基盤構築・運用サービス、データ活用コンサルティング、データ活用分析研修、生成 AI 総合支援サービスなど様々な支援のあり方を紹介いただきました。 写真: クラスメソッド株式会社 三鴨様によるセッション まとめ セッション後には参加者同士のグループディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。 名古屋でご登壇いただいたタキヒヨー様とクラスメソッド様に共通していたのは、 データをいかに集め、活かせる状態に整えるか という土台の重要性と、 小さい成功体験を少しずつ積み重ねる という進め方のベストプラクティスでした。AI を活用している企業様は、データや周囲の巻き込み方など AI 以外の部分にもプラクティスを持っておられることが伝わるセッションでした。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした名古屋・3 日目に続き、次回は翌日開催の名古屋・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート タキヒヨー、生成 AI を活用し社内業務効率化と 450 時間超の工数削減を実現。Amazon Bedrock を衣服デザイン等に適用、デジタル人材育成を推進 中堅・中小企業でも広がる生成 AI。企業の成長にも貢献 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

本稿は株式会社八十二長野銀行と AWS Japan の共同執筆により、AWS 人材育成プロジェクトを通じて得られた成果と今後の取り組みをお伝えするものです。 はじめに 株式会社八十二長野銀行 (以下同行) は、長野県長野市に本店を置く地域密着型の金融機関です。同行では「クラウドファースト」を掲げ、AWS を活用したシステム開発案件が年々増加しています。こうした流れの中で、分散系人材を増やし、クラウド技術を担える人材の育成が喫緊の課題となっていました。 この課題に対して同行と AWS は、2025 年度にシステム部門の新入行員 21 名を対象とした Enterprise Skills Transformation の Guild Incubator (以下 EST)  というプログラムを実施しました。 EST とは、AWS が提供する伴走支援型の人材育成プログラムです。一般的な短期間の研修プログラムとは異なり、専任のインストラクターがお客様に付き、組織の状況や課題をヒアリングした上で、人材育成のゴール設定からカリキュラム設計、研修の実施・改善までを支援します。 本記事では、4 ヶ月間にわたる EST の取り組み内容と、そこから得られた成果を共有します。 EST 実施の背景 同行では、上述の人材育成の課題を抱える中、分散系人材育成に向けた第一歩として、AWS の EST プログラムの導入を決定しました。 EST の実施内容 今回の EST では、専任のインストラクターが同行の状況や受講者のスキルレベルを踏まえ、以下の研修プログラムを設計・実施しました。 イノベーションカルチャーの体感からスタート 研修の初日には、AWS が提供する「New Builder Session」を 1 日かけて実施しました。New Builder Session とは、アマゾンのイノベーションカルチャーを体感するプログラムです。お客様を起点に考える「Working Backwards」をはじめとする、AWS のサービス開発の根幹となる考え方やメカニズムを、ワークショップ形式で学びます。 技術的なスキル習得に先立ち、「なぜクラウドを学ぶのか」「お客様にとっての価値とは何か」という本質的な問いに向き合うことで、受講者が主体的に学ぶためのマインドセットを醸成し、その後 4 ヶ月間にわたる研修の土台を築きました。 注: EST プログラムの中で、New Builder Session を必ず実施するというわけではありません。 New Builder Session 実施中の様子 1/2 New Builder Session 実施中の様子 2/2 研修設計の基本方針 本研修は 4 ヶ月間にわたり、「知識」「実践」「姿勢」の 3 つの軸で設計しました。同行には週あたり約 10 時間の学習時間を確保いただき、単なる座学による知識習得にとどまらず、実際に手を動かしてアプリケーションを開発する実践力の養成、そして主体的に学び続ける姿勢の醸成を目指しました。 ブレンデッドラーニングによる学習設計 学習の主軸は AWS Skill Builder によるデジタル学習としました。 AWS Skill Builder とは、600 以上のオンデマンド動画で AWS について学習できるウェブサービスです。動画コンテンツのみならず、 実際に手を動かして学ぶ AWS Builder Labs や、チームで AWS 環境の課題解決をすることでポイントを競い合う AWS Jam などのコンテンツがあります。これらは Skill Builder 側で用意されている AWS アカウントを使用するため、お客様の AWS アカウントを用意せずに利用できます。 有償のサブスクリプションに加入いただくことで、これらすべてのコンテンツに無制限でアクセスでき、受講者は自身のペースで体系的に学習を進めることができます。 受講者は AWS Skill Builder を活用し、AWS の基礎から応用までを体系的に学習しました。一方で、動画視聴のみでは理解が難しい領域については、インストラクターによる対面でのオンサイト研修で復習・補強する構成としました。 さらに、習得した知識を実際の AWS 環境で活用するハンズオンや、上述の AWS Jam といったイベントも実施し、知識の定着と実践力を鍛えました。 このように、セルフラーニング (動画視聴による個人学習) とグループラーニング (オンサイト研修でのチーム学習) を組み合わせた「ブレンデッドラーニング」の設計を採用することで、個人で考えて調べながら学習する時間と、チームでの議論によって別の意見を聞いたり、自分の考えを発信することで理解を深める仕組みにより、高い学習効果の実現を目指しました。 知識: 中級相当の認定資格取得を目指す 知識面では、初級相当の認定資格ではなく中級に相当する Associate レベルの認定資格である AWS Certified Solutions Architect – Associate (SAA) の取得を目標に設定しました。4 ヶ月間にわたり週 10 時間の学習時間を確保いただけるからこそ、AWS 初学者の多くが最初に目指す初級レベルの認定資格にとどまらず、あえて中級レベルの資格まで手を伸ばす構成としました。 認定資格対策としては、受講者がオンサイト研修以外の隙間時間にも繰り返し練習問題に取り組めるよう、生成 AI を活用した学習支援アプリケーションを開発し、同行の環境にデプロイする形で配布しました。受講者には日常的に SAA の練習問題に取り組んでもらうことで、知識の定着を図りました。 実践: チームでのアプリケーション開発 本研修の大きな特徴として、認定資格の取得にとどまらず、チームでのアプリケーション開発を通じて「実践力」を鍛えるプログラムを組み込んだ点が挙げられます。 チームごとに自由に開発ができる AWS のサンドボックス環境 (Amazon SageMaker Studio の Code Editor) で、Amazon Q Developer を用いて、”現場での課題” を解決するデモアプリケーションの設計、開発に取り組みました。 初学者ながらも、AWS のベストプラクティスを参考にして、初期段階からセキュリティやコストを意識したアプリケーションの開発手法を学びました。 研修中の様子 1/2 研修中の様子 2/2 姿勢: 主体性を引き出す研修設計 今回の研修は、受講者の主体性を最大限に引き出すように設計しました。発表会をはじめとするアウトプットの機会を複数用意し、受講者全員、必ず一度は全体で発表をする機会を設けました。また、進捗が早い方はどんどん先に進められるように、追加のコンテンツも用意しました。 一方で、研修の中盤以降、受講者間で理解度に差が生じてきたため、フォローアップミーティングを実施し、理解に苦しんでいる方へのフォローアップにも注力しました。全員を置き去りにしない丁寧なサポート体制を整えることで、受講者一人ひとりの成長を支援しました。 EST の成果 学習への取り組みについて、受講者全員が AWS Skill Builder で 70 時間以上の動画学習を完了しました。これにより、受講者全員が AWS の基礎的なスキルを身につけ、クラウド人材としての第一歩を踏み出したといえるでしょう。 認定資格の取得 SAA に 21 名中 17 名 (合格率 80%) が合格しました。 グループ開発の成果 グループ開発では、4 チームがそれぞれ部内の課題を調査し、その解決策となるアプリケーションを開発・発表しました。RAG (Retrieval-Augmented Generation) を活用した社内ドキュメント検索アプリケーションや、PowerPoint スライドの自動生成アプリケーションなど、いずれも実務に即した実用的なテーマが選定されました。 各チームが開発したアプリケーションはすべて実際に動作するものであり、非常に質の高い成果物となりました。成果発表会では、同行の幹部から「全くクラウド経験やスキルがないところから、4 ヶ月でここまでできることに感動している」とのコメントをいただきました。 成果発表会の様子 1/2 成果発表会の様子 2/2 各チームが開発したアプリケーションの概要 参加者の声 研修後のアンケートでは、受講者から以下のような声をいただきました。 「知識のインプットはオンデマンドがメインであったため自分のペースで確実に進めることができ、オンサイトではアウトプットがメインであったため、学習サイクルを効率的に回すことができた。効果的に知識とスキルが定着したと感じた」 「研修前はクラウドが何か分からない状態でしたが、4 ヶ月の研修で実践的な知識と技術を身につけることができました。知識をインプットするだけでなく、実際に AWS を操作する機会が多かったため、スキル面でも成長を感じることができました」 「AWS 含め、クラウドの概念さえ知識がないところからのスタートでしたが、チームでのアプリ開発ができるまで知識・技術が身についたため、とてもよかったと感じています。Amazon Q Developer などの生成 AI の活用方法についても学ぶ機会となり、AWS 研修開始前よりも AI を使ってできることが増えました」 「講師の方が用意してくださったコンテンツが非常に面白く、最初から最後まで楽しんで学習することができた。また、ただ話を聞いているのではなく受講者同士の意見交換の時間が非常に多く効率的な学習につながった」 「AWS とホスト開発の研修を並行して進める中で、AWS のメリット・デメリットだけでなく、ホストシステムについて客観的な視点でより理解を深めることができた。クラウドについて学ぶことで、今後のキャリアや自分のやりたいことを見つけていくことに非常に役立ったと感じる」 また、今後の意欲として「AWS Certified Solutions Architect – Professional 取得を目指したい」「今後も AWS を活用してアプリケーションを開発したい」といった声も多数寄せられました。 受講者が研修終了後もさらなる高みを目指す意欲を示していることは、本研修が知識やスキルの習得だけでなく、クラウド技術への興味・関心を深く醸成できた証拠であると考えています。 研修責任者の声 研修後、本研修の責任者から以下のような声をいただきました。 「行内研修では見たことがないくらい参加者が楽しそうに学んでおり、新しい発見があった。今回の人材育成を AWS に任せてよかった。」 「AWS は単なるインフラサービスではなく、AWS を活用することで銀行が自ら DX に向けた内製開発に取り組めるようになると感じた。」 今後の取り組み 今回の EST を通じて、クラウド技術の基礎を備えた若手人材を育成しました。しかしながら、ここがゴールではありません。同行では今後、以下の取り組みを検討しています。 まず、今回育成した若手人材が研修で培ったスキルを実務で発揮できるよう、AWS 活用案件への参画など実践の機会を積極的に設けていくことです。知識を現場で活かすことで、さらなるスキルの定着と成長が期待できます。 次に、リーダー・中堅層やクラウド育成担当者を含めた、より幅広い層へのクラウドスキル浸透です。若手層だけでなく組織全体のクラウドリテラシーを高めることで、分散系人材育成をより確実なものにしていきたいと考えています。 まとめ 今回の EST を通じて、同行はクラウド人材育成において大きな一歩を踏み出しました。 一般的な短期間の研修プログラムでは、あらかじめ決められたカリキュラムを数日間で実施し、研修後のフォローは受講者に委ねられます。一方、EST は研修の実施だけでなく、お客様が目指す組織変革に合わせたゴール設定やカリキュラム設計から始まり、研修期間中も受講者の理解度に応じ専任インストラクターが柔軟にコンテンツを調整しながら伴走する人材育成プログラムです。 今回の研修においても、中盤以降に受講者間で理解度の差が生じた際には、フォローアップ体制を迅速に整えることで、全員を置き去りにしない支援を実現しました。こうした伴走支援があったからこそ、AWS 初学者 21 名から SAA 合格率 80%、そして全チームが実際に動作するアプリケーションを完成させるという成果につながったと考えています。 AWS では、クラウドの人材育成経験豊富なインストラクターが、研修プログラムと様々な育成アプローチにより、企業や教育機関のクラウド人材育成をご支援します。ご興味をお持ちの方は、ぜひ AWS アカウントチームまでお問い合わせください。

はじめに こんにちは。デザインストラテジストの松迫です。 「AIツールを導入したが、その後定着しない」——こんな経験はないでしょうか？ 本記事では、行動科学に基づいた「ハビットデザインメソッド」を使って、 ツール定着の壁を乗り越える具体的な方法をお伝えします。 私は習慣化を促すUXデザインの研究や実践を通じて、この方法論を体系化し、 書籍『あのサービスはなぜ継続率が高いのか？』で紹介しています。 今回は、その内容から「社員のAI・デジタルツール利用の習慣化」というテーマに絞って、習慣化のメカニズムやそのコツをお伝えしていきたいと思います。 一度使い始めたツールも、習慣にならないと元に戻る 便利で効率化につながるAI/DXツールであったとしても、導入初期を過ぎると使われなくなってしまう現象はよく起きます。 このような現象が起きやすい大きな理由の一つは、 「古い習慣の力は非常に強く、気を抜くとすぐに元の行動パターンへ戻っていく」 という人間の特性です。 たとえば、 ChatGPTを導入したが、結局検索はGoogle検索に戻る ナレッジ共有ツールを入れたが、口頭確認に戻る ToDo管理ツールを導入したが、入力をしない元の状態に戻る といったケースです。 特にAIツールは、便利だけれど「なくても仕事はできる」Nice to haveツール（あればうれしいけど必須じゃないツール）になりやすい特徴があります。 基幹システムのようなMust haveツール（必須ツール）は、なければ仕事ができないので半強制的に使われます。 しかし、AIアシスタントや情報整理ツールなどが社員の中でNice to haveなものだという認識のままだと、なかなか利用が定着しません。 そのため、特に「なくても仕事はできる」ツールであるほど、“習慣になるまで支援をする設計”が必要なのです。 習慣になるまでは平均66日かかる そもそも人の行動が習慣になるまでどのくらいかかるのでしょうか？ ロンドン大学のPhilippa Lally らによる研究（2009）では、人が行動を習慣化するまでには平均66日かかるとされています（内容によって定着までの日数にはばらつきがあります）。 これを念頭におくと、AIツール導入後にすぐに利用が定着するということはほぼなく、2ヶ月くらい利用を継続して初めて習慣になっていくということです。 そして、習慣化するまでは前述の通り、古い習慣の引力が働くので、元の行動に戻りやすい期間でもあります。 そのため、「1週間くらいは使ってたけど、そこから使わなくなっちゃったな」ということが誰にでも起きやすいのです。 だからこそ、この期間に、 繰り返し触れる 使うきっかけがある 面倒なく使える 小さな成功体験がある というような、繰り返し使いやすい状態をつくれないと、習慣化の壁を超えられません。 習慣は、「〇〇したら□□する」という脳内の紐づきでできています。 習慣化した状態とは「〇〇したら□□する」という紐づいた行動が“自然に”行われる状態です。 そのため、約2ヶ月間の間に、「〇〇したら□□する」という紐付きを育てていく必要があるのです。 たとえば、 会議後 → AIで議事録整理 提案前 → AIで文章チェック 営業準備 → AIで仮説作成 のように、AIを使った行動を既存業務行動と結びつけていくことで、その行動が次第に脳の“デフォルト行動”になっていきます。 重要なのは、最初～約2ヶ月間の「便利だから使う」という意識的に使う状態を経て、ほぼ無意識的に「自然と使っている状態」をつくることです。 そうなると古い習慣が新しい習慣にアップデートされた状態になります。 35のハビットデザインメソッド 私は、習慣化を促すための具体的な方法を「35のハビットデザインメソッド」として体系化しています。 35のハビットデザインメソッドの一覧（著者作成） まず、習慣化しやすい体験を作るには 1. 準備 2. きっかけ 3. 行動 4. 報酬 というサイクルをつくることが重要です。 比較的習慣化しやすいシンプルな行動は必ずしもサイクルを全て網羅する必要はありませんが、習慣化の難易度の高い行動ほど、丁寧に各サイクルでサポートすると習慣化がしやすくなります。 ここでは、35個すべてをご紹介はできませんが、特に重要な15個のコアメソッドの概要をご紹介します。 「準備」 1.チェーンプランニング ：「〇〇したら□□する」と既存習慣に新行動を紐づける 2.具体ゴールセッティング ：目標を具体的に設定し、達成への行動を具体化する 3.簡単スタートセッティング ：行動を始める手間を極限まで小さくする 「きっかけ」 7.欲求プラス ：やる気が出る他の行動を、新行動の前や中にプラスする 8.クエスト＆リワード ：達成すべきクエストと報酬を用意し、継続意欲を高める 9.損失回避アクティベート ：損したくない心理を刺激して、行動を促す 10.予約・約束セッティング ：予約や約束をすることで確実な実行を促す 「行動」 18.超ミニマムゴール ：絶対できるレベルの小さな行動をゴールにする 19.エブリデイハビット ：毎日触れることで自然な習慣になることを促す 20.楽しさドリブン ：楽しい体験でやる気をアップさせる 21.親切フォローアップ ：親切なフォローで「親切に応えたい」気持ちを引き出す 「報酬」 27.簡単レコード ：実施記録が簡単につけられて、実績が目に見えるようにする 28.すぐさまごほうび ：行動直後にごほうびを与える 29.ほめちぎりモチベート ：行動できたらほめちぎって、継続意欲を高める 30.ちょっとずつサクセス ：小さい単位で成功体験を得られるようにする 習慣化しやすい体験をつくるには、これらのメソッドから、習慣にしたい新しい行動と相性がよさそうなものを選んで、施策やUXデザインに落とし込んでいきます。 習慣化の難易度の高そうな行動については、複数のメソッドを組み合わせてサイクルをできるだけ丁寧に回すようにするとよいです。 ポイントは、「やる気に頼らない」ことです。 やる気だけに頼ってしまうと、やる気が十分にない人は続かなくなってしまいます。 もちろんやる気を高めることも重要ですが、それ以上に「やる気に頼らずとも続けやすい仕組みをつくる」ことを意識して施策や設計を考えることが大切です。 能動ドライブと受動ドライブ 人の習慣化を促すハビットデザインの方向性には、大きく2種類あります。 それは「能動ドライブ」と「受動ドライブ」です。 35のハビットデザインメソッドも、明確に分類が難しいものもありますが、それぞれこのどちらかに分類されます。 能動ドライブ その人の「やりたい」という気持ちを後押しして行動を促す方法です。 例： - 達成したい - 継続したい - 成果を出したい - 新しいAIを使いこなしたい 受動ドライブ 「やらなきゃいけない」状態をつくり行動を促す方法です。 例： - AIを使わなければならないルールにする - 上司への報告が必要 - AIを使わないと次工程に進めない 私のおすすめは、まずは「能動ドライブ」に該当するメソッドを検討して、それだけではなかなか定着させることが難しいと感じる場合は「受動ドライブ」のメソッドも活用するという順序です。 それは、「受動ドライブ」はある種の強制力を使うので、社員がストレスを感じることも起きやすく、できるだけその人の能動性を活かす「能動ドライブ」で習慣化できる方が理想的だからです。 とはいえ、能動ドライブだけではうまく定着しないということが仕事の現場ではよく起きるので、業務では、適切に受動ドライブを組み込むことも必要です。 最初はルールなどを設定して“半強制”でも、繰り返すことで自然な習慣へ変わっていきます。 社員の習慣化を促す2つのアプローチ それでは、実際にハビットデザインを実装していく方法についてです。 方法として「開発を伴わない仕組み化」と「開発を伴う仕組み化」の2つのアプローチがあります。 ① 開発を伴わない仕組み化 まずおすすめなのが、システム開発などをせず、すぐにできる仕組みづくりです。 既存のツールをうまく使ったり、ルールや仕掛けを導入するだけでも、習慣化しやすい体験をつくることが可能です。 たとえば： 週次会議で新しいAI活用事例を1分共有（厳密デッドライン） 「AIで調べてから質問する」ルール化（チェーンプランニングなど） 報告書に「AI推敲」の実施チェック欄をつける（約束・予約セッティング） などです。 特に重要なのは、「使うタイミングを固定すること（チェーンプランニング）」です。 「好きな時に使ってください」は、実は習慣化しにくい設計です。 それよりも「会議前にAI議事録機能をONにする」、「顧客メール送付前にAIに文章チェックをしてもらう」など、具体的な用途と使うタイミングをおすすめし、そのタイミングで使うことを繰り返すことが習慣化への近道です。 ② 開発を伴う仕組み化（UXデザイン） 次に重要なのが、UXレベルでの設計です。 こちらは、ツールの体験そのものに組み込めるため、より強力です。 自社でソフトウェアを開発する際や、クライアント企業向けに開発を行う場合などは、ぜひ習慣化しやすい体験を組み込みましょう。 たとえば： AIを使うまでのクリック数を極限まで減らす（簡単スタートセッティング） 連続記録機能をつける（損失回避アクティベート） AIの活用実績でレベルアップしていく（クエスト＆リワード） などです。 ソフトウェアのUXに組み込む場合は、本当にいろんな仕組みを取り入れることができます。 極限まで使い始める手間を小さくしたり、ごほうび要素を用意したり、使わないと損するような仕組みを取り入れたりと、いろんなアプローチが可能です。 35のメソッドをうまく組み合わせ、習慣化しやすい体験を丁寧につくり上げていくことができます。 「能動/受動ドライブ」と「開発を伴わない/伴う仕組み」を掛け合わせて4象限をつくると下図のようになります。 （著者作成） 一番取り入れやすいおすすめは左上の「手軽で後押しする方法」ですが、より強力な方法にしたい場合は“右”に移動し、より丁寧なUXをつくりたい場合は“下”に移動していくイメージです。 具体的なハビットデザインアイデア 先ほど少しハビットデザインの施策例を紹介しましたが、より具体的にハビットデザインメソッドを使ってどんな施策やUXデザインが可能かの一例を紹介します。 これはほんの一例なので、「どんなことを習慣化してほしいか」に合わせて、皆さん自身でハビットデザインメソッドから施策やUXデザインのアイデア出しをして、実装していってください。 ①「開発を伴わない仕組み化」でのアイデア例 1. よく使うブラウザアプリの隣りにAIアプリを配置 　（能動ドライブ：簡単スタートセッティング） AIを立ち上げるボタンが階層の深いところにあったり、すぐにクリックできない場所にあると、そもそも使うことが面倒になるため、いつも使うアプリの横など、使うことが自然に促される場所にAIアプリを配置するように促します。 2. “まずAIで調べる”という行動指針をつくる 　（能動ドライブ：チェーンプランニング） 質問前に「（AIでわかることは）まずAIで調べる」を行動指針化することで、質問する前のAI活用の定着を促します。 3. AI活用目標の設定 　（能動ドライブ：具体目標セッティング、受動ドライブ：だれかにコミットメント） 各個人がAI活用目標を設定し、上司への進捗・達成の共有をルール化すると、取るべき具体的な行動が明確になり行動に移りやすくなります。 4. AI議事録の自動ON設定 　（能動ドライブ：簡単スタートセッティング） オンライン会議ツールの設定で、デフォルトでAIが議事録を取る設定がある場合はONにしておくと、自動的にAIで議事録を取るようにできます。 5. AIの業務削減効果を共有 　（能動ドライブ：損失回避アクティベート） 「○○の用途にAIを活用すると、平均30%の業務時間削減効果があります」というように、具体的な用途での定量効果を見せることで、“使わない”ことの損失を意識させて、利用を促します。 ②「開発を伴う仕組み化（UXデザイン）」でのアイデア例 1. AIを業務フローの中に埋め込む 　（能動ドライブ：簡単スタートセッティング） 別アプリではなく、既存業務で使うソフトウェアの中にAIを統合することで利用率が上がります。ただAIボタンをつけるだけでは不十分で、利用者のソフトウェア上の業務動線を意識して、パッと使いやすい場所に配置することが重要です。 2. AIでの業務削減効果の参考値が毎回表示される 　（能動ドライブ：すぐさまごほうび） AIを使ってもどれだけ業務効率が上がったかなどがわかりにくいと、脳が報酬を受け取れません。AIを使うたびに、すぐにその行動でどれだけ業務削減効果に繋がったかの参考値を表示することで、報酬になり「効率化したならまた使おう」というモチベーションにも繋がります。 3. 利用記録を可視化する 　（能動ドライブ：簡単レコード） 連続利用日数や毎日の利用状況を表示すると、自身の利用実績が見えること自体がごほうびになり「使い続けたい心理」が働きます。これは学習アプリなどでもよく使われる強力な手法です。 4. AI使おうリマインドメール 　（受動ドライブ：親切フォローアップ） 毎月の請求書を作成する時期が来たら、「AIで請求書を作成しよう」というフォローメールとワンクリックで請求書作成画面に飛べる仕組みをつくります。 これまでの手動の方法でつい作ってしまうことを防ぎ、自然にAIでつくる流れを生みます。 5. ベタ褒めしてくれるキャラ設定 　（能動ドライブ：ほめちぎりモチベート） AIを使う体験の中にほめられる要素がないと、気分よく使ってもらえません。 効率化だけでなく、しっかり使っている中でベタ褒めしてくれるキャラを用意することで、よりAIを使うことにごほうび要素を感じて、使いたい気持ちを高めます。 手軽で効果の高い方法から始めよう AI/DX定着で大切なのは、いきなり大きなことをしようとするより、小さなやりやすいことから始めることです。 ハビットデザインメソッドを使った「開発を伴わない仕組み化」からまず始めることをおすすめします。 AIを使うタイミングを決める（〇〇したらAIを使う） 毎日1回使うだけで成功とする 5分だけAIを使ってみる時間をつくる ごほうび要素を用意する 小さなルールを決める といった、すぐできる工夫からでOKです。 社員（自社/クライアント先）に対して、こういう小さな施策から取り組んでもらい、そこから施策やUXデザインを拡大していくとよいでしょう。 まずは自分自身が、うまく継続して使えてなかったツールを、小さな仕組みを取り入れて継続するところから始めてもよいかもしれません。 注意点としては、「ハビットデザインメソッド」は定着のための万能アイテムというわけではありません。 そもそも、AIツールであれば、AIを使う価値をしっかり伝えることが重要ですし、どういうユースケース（用途）があるのかを伝えることも重要です。 また、カスタマーサクセスの領域ですが、そのツールを迷いなく使い始めることができるようにオンボーディングを丁寧に行うことや、細かい使い方のTipsをシェアすることも大切です。 こういった基本的な取り組みに、ハビットデザインを取り入れると、より自然に行動を定着させていくことができます。 また、ハビットデザインメソッドを使った施策やUXを考える時は、実験や検証をしながら、効果を確かめながら適切に体験を調整したり、場合によっては別のメソッドを使った施策を追加したり、入れ替えたりすることも重要です。 この施策は有効そうだと仮説を立てても、うまくいかないことはもちろん起きえます。大切なことは、科学に基づく習慣化のメソッドを拠り所にして、試行錯誤してよい方法を探っていくプロセス自体です。 アイデアは一人で考えてももちろんよいですが、複数人が集まってブレストして、いいアイデアをピックアップしていくと幅広い施策を考えられます。 AI時代に重要なのは、「便利で高機能なツールを導入すること」に加えて「社員が自然と使い続ける状態をつくること」です。 特にNice to haveなツールには、その視点は必須といってもよいでしょう。 ぜひ、社員のAI/DX活用を習慣化の視点から何かできることはないかと検討し、習慣化を促す施策やUX設計を考えてみてください。