FM・PMにおける設備台帳とは

FM・PMにおける設備台帳とは、建物や施設に設置されている設備の情報を、管理・点検・修繕・更新のために整理した台帳です。単に「設備名と設置日を記録する一覧表」ではありません。商業施設やオフィスビル、複合施設などを管理する現場では、テナント対応、法定点検、修繕計画、資産価値の維持に関わる重要な情報基盤になります。設備台帳に含める情報としては、主に次のようなものがあります。

• 電気・通信・空調・給排水・消防・厨房設備などの設備情報
• 図面・竣工書類・工事資料
• 法定点検の結果・次回期限・届出書類
• 修繕履歴・工事費・設備の更新サイクル
• テナント入れ替え時の確認事項や対応履歴

商業施設や一定規模以上の建物では、建築基準法や消防法に基づく定期報告・点検報告が関係するケースもあります。そのため、設備台帳は日常管理だけでなく、行政への報告や監査対応に必要な資料をすぐに確認できる状態にしておくことが重要です。

商業施設の設備台帳をExcelで管理する5つの課題

Excelは手軽に使えるため、設備台帳の管理にもよく利用されます。一方で、複数物件や多数のテナントを管理する商業施設では、Excelだけの管理に限界を感じる場面も少なくありません。

1. 法定点検の期限・結果が物件ごとに分散する

法定点検や定期報告に関する情報は、期限管理が特に重要です。物件ごとにExcelファイルが分かれていたり、点検結果がPDFや紙で保管されていたりすると、次回期限や是正対応の状況を横断的に確認しにくくなります。Excelは一覧管理には便利ですが、期限が近づいた情報の抽出や、点検結果・届出書類とのひも付けには工夫が必要です。商業施設の設備管理でExcelの限界を感じやすいのは、期限管理、証跡管理、関連書類の管理が同時に求められる場面です。もしExcelの更新漏れで点検義務を怠ってしまった場合、コンプライアンス違反として行政指導の対象になるだけでなく、最悪のケースでは施設の営業停止など、企業の信用を揺るがす重大なリスクに直結します。

2. 複数施設の修繕計画を横断して把握できない

PM担当者にとって、修繕履歴や更新予定を横断して把握することは、予算計画や中長期の資産管理に直結します。しかし、物件ごとにExcel台帳が分かれていると、どの設備が老朽化しているのか、どの施設で修繕費が集中しているのか、次年度以降にどの程度の更新コストが見込まれるのかを把握しにくくなります。結果として、突発的な修繕対応が増えたり、優先順位の判断が担当者の経験に依存したりすることがあります。このように「後手後手」の修繕が続くと、本来なら計画的に抑えられたはずのコストが数倍に膨れ上がるだけでなく、突然の設備トラブルでテナントの営業を止めてしまい、損害賠償に発展する恐れもあります。

3. テナント入れ替えのたびに設備情報の確認に時間がかかる

商業施設では、テナントの入れ替えに合わせて、電気容量、空調、給排水、厨房設備、通信環境などの確認が必要になります。しかし、設備情報がExcel、図面、メール添付、共有フォルダ、担当者の個人PCなどに分散していると、必要な情報を探すだけで時間がかかります。さらに、見つけたExcelが最新版かどうか判断できない場合、現地確認や関係者への問い合わせが増え、対応スピードが落ちてしまいます。

4. 担当者に属人化し、異動・退職で情報が失われる

プロパティマネジメントにおける台帳管理では、担当者の経験や記憶に頼っている情報が少なくありません。「あの設備の履歴は前任者しか知らない」「どのフォルダに図面があるか分からない」「修繕時の経緯がメールにしか残っていない」といった状態になると、異動や退職のたびに引き継ぎ負荷が大きくなります。Excelは自由度が高い反面、入力ルールや保存場所が統一されにくく、属人化を招きやすい点に注意が必要です。

5. 外部委託先・テナントとの情報共有が煩雑になる

設備管理では、ビル管理会社、工事会社、点検会社、テナントなど、社外の関係者と情報を共有する場面も多くあります。Excelをメールで送付する運用では、どのファイルが最新版か分からなくなりやすく、誤送信や不要な情報共有のリスクも高まります。特に、図面や設備情報には施設運営上の重要情報が含まれるため、必要な相手に必要な範囲だけ共有できる仕組みが求められます。

Excel管理の課題解決には、設備台帳管理システムの一元管理が重要

Excel管理で起きる課題の多くは、単にExcelの機能不足だけが原因ではありません。設備情報、点検情報、図面、修繕履歴、テナント対応履歴が別々に管理されていることで、必要な情報をすぐに確認できない状態になっていることが大きな要因です。そのため、設備台帳の管理を見直す際は、まず「どのツールを使うか」ではなく、「どの情報を、誰が、どのタイミングで確認・更新できる状態にするか」を整理することが重要です。複数物件の設備台帳を管理する方法としては、設備情報を物件・フロア・テナント・設備単位で整理し、点検結果や修繕履歴、図面などの関連情報をひも付けて管理する仕組みが有効です。設備台帳を一元管理できる状態にすると、次のようなメリットがあります。

• 最新の設備情報を関係者が同じ場所で確認できる
• 法定点検の期限や結果を横断的に把握できる
• 修繕履歴や更新予定をもとに中長期の計画を立てやすくなる
• 図面や届出書類などの関連資料を設備情報とひも付けられる
• 担当者交代時の引き継ぎ負荷を軽減できる
• 外部委託先やテナントに必要な情報だけを共有しやすくなる

特に商業施設では、テナント管理と設備情報の一元化が重要です。テナントの入れ替えや改装工事のたびに、設備容量、図面、過去の工事履歴、行政への届出書類などを確認する必要があるため、情報が分散しているほど確認作業に時間がかかります。

失敗しない設備台帳管理システムの選び方

設備台帳をExcelから脱却してシステム化しようと考えた場合、選択肢は大きく分けて2つあります。

• 高度な機能があらかじめ備わった「設備管理の専用パッケージシステム」
• 自社の運用に合わせて自由に画面を作れる「汎用的なWebデータベース」

システム選定で失敗しないための最大のポイントは、「自社独自の運用ルールや、既存のExcelの手軽さをそのまま活かせるか」という点です。専用パッケージは多機能な反面、コストが高額になりがちで、自社の業務フローをシステム側に合わせなければならないケースも少なくありません。そのため、「コストを抑えつつ、今使っているExcelの使いやすさを活かして自社にフィットしたシステムを作りたい」という企業の間では、Webデータベースを活用して自社専用の設備台帳管理システムを構築する方法が選ばれています。
設備台帳をWebデータベースへ移行すると、Excelのように一覧で確認しやすい利便性を活かしながら、情報の一元管理、権限設定、更新履歴の確認が格段にしやすくなり、業務の課題をスムーズに解決できます。たとえば、Webデータベースを活用した設備管理システムでは、次のような具体的なメリットが得られます。

設備台帳をWebデータベースで管理する場合、重要なのは「ExcelをそのままWeb化すること」ではありません。現場で使いやすいように、物件、フロア、設備、点検、修繕、図面、テナントなどの情報をどのように関連付けるかを設計することです。この設計ができていないと、せっかくシステム化しても「入力しづらい」「必要な情報を探しにくい」といった状態が残ってしまいます。そのため、自社に最適な設備台帳管理システムを構築する際は、業務の流れに合わせて情報の持ち方を整理することが大切です。そこで、数あるWebデータベースの中でも、「既存のExcelの手軽さを最も活かしやすく、現場に合わせた柔軟な設計が低コストで実現できるツール」として、多くの企業に選ばれているのが「プリザンター」です。

プリザンターを活用した設備台帳管理方法の例

設備台帳をWebデータベースで一元管理する方法の一つとして、プリザンターの活用が考えられます。プリザンターは、ノーコード・ローコードで業務アプリを構築できるWebデータベースです。Excelのような一覧で確認しやすい利便性を活かしながら、情報の一元管理、権限設定、履歴管理、ダッシュボード化などを行うことができます。たとえば、商業施設の設備台帳管理では、次のような使い方が考えられます。

• 物件・フロア・テナント・設備を階層的に管理する
• 設備ごとに図面、点検結果、修繕履歴、工事資料をひも付ける
• 法定点検の次回期限や対応状況を一覧で確認する
• 複数施設の修繕履歴や更新予定をダッシュボードで可視化する
• 担当者や外部委託先ごとに閲覧・編集権限を設定する
• Excelからデータを移行し、必要に応じてExcel出力も行う

プリザンターを活用することで、設備台帳、点検情報、図面、修繕履歴を別々に管理するのではなく、同じ情報基盤の上で確認・更新しやすくなります。ただし、プリザンターは柔軟性が高い分、自社の業務に合わせた設計が重要です。どの情報を台帳化するのか、誰が更新するのか、どの画面を日常的に使うのかを整理したうえで構築することで、現場で使われる設備台帳管理システムに近づきます。

設備台帳管理システムを導入する際の進め方

設備台帳の管理を見直す際、最初からシステム選定に入る必要はありません。現在の情報がどこにあり、どの情報から一元管理すべきかを整理しないまま進めると、システム化しても使われない台帳になってしまうことがあります。ここでは、ExcelからWebデータベースへの移行を検討する前に取り組みたい3つのステップを紹介します。

ステップ1：今ある台帳・書類を棚卸しする

まずは、設備情報がどこに散らばっているかを書き出します。Excelファイル、紙の書類、共有フォルダ、メール添付、個人PC、委託先が保管している資料など、形式を問わず洗い出すことが重要です。設備台帳、点検報告書、図面、修繕見積、工事完了報告書など、関連資料も含めて確認します。この段階で意識したいのは、「整理されていない情報をシステムに移しても、整理された状態にはならない」という点です。まずは現状を可視化し、重複している情報、古い情報、更新責任が曖昧な情報を把握することが第一歩になります。

ステップ2：一元管理する情報の優先順位を決める

次に、どの情報から一元管理するかを決めます。すべての情報を一度にシステム化しようとすると、項目設計が複雑になり、現場の入力負荷も大きくなります。優先すべきなのは、更新漏れや確認遅れが業務リスクにつながる情報です。たとえば、法定点検の期限管理、テナント入れ替え時に必ず参照する設備情報、修繕判断に必要な老朽化状況などは、早い段階で一元管理の対象にしやすい情報です。最初から完璧な台帳を目指すのではなく、業務上のリスクが高い情報から整備することで、現場にとって使う意味のある仕組みになります。

ステップ3：ExcelとWebデータベースの使い分けを決める

Excel管理を見直すといっても、Excelを完全になくす必要はありません。重要なのは、元データやマスタ情報をWebデータベースに集約し、必要に応じてExcelを分析や帳票出力に活用するという使い分けです。たとえば、設備情報、点検期限、修繕履歴、図面リンクなどはWebデータベースで一元管理し、会議資料や予算検討用の集計表はExcelに出力して加工するといった運用が考えられます。このように役割を分けることで、Excelの使いやすさを残しながら、情報の分散や版管理の課題を減らすことができます。

設備台帳管理システムの構築でSMSデータテックが支援できること

設備台帳管理システムを構築する際は、ツールの導入だけでなく、自社の業務に合わせた情報設計が重要です。特にFM・PM業務では、物件、フロア、設備、点検、修繕、図面、委託先、テナントなど、関係する情報が多岐にわたります。SMSデータテックでは、プリザンターの導入支援を通じて、設備台帳管理に必要な設計・構築・運用改善を支援しています。具体的には、次のような支援が可能です。

• 現在のExcel管理の課題や業務内容を可視化する事前ヒアリング
• 実務に合わせた画面・項目設計
• 担当者が直感的に使えるダッシュボードの構築
• 既存システムとの連携や二重入力の解消
• セキュリティ要件に応じた環境設計・構築
• 導入後の運用改善・活用支援

プリザンターは柔軟性の高いツールですが、自由度が高いからこそ、最初の設計が使いやすさを大きく左右します。項目を増やしすぎると入力負荷が高くなり、反対に情報が不足していると業務に活用しにくくなります。そのため、設備台帳管理システムを導入する際は、現在の管理方法や業務フローを整理したうえで、自社に合った形で設計することが大切です。SMSデータテックは、インプリム社主催の「Pleasanter Partner Award 2025」において「Top Revenue Award（トップレベニュー賞）」を受賞しており、プリザンターの導入支援・構築・運用サポートを通じて、企業の業務効率化やDX推進を支援してきた実績があります。

プリザンターによる設備台帳管理システムの導入事例

SMSデータテックでは、JR西日本デイリーサービスネット様におけるプリザンター活用を支援した事例があります。
同社では、駅構内の店舗や商業施設、ホテルなどを運営するなかで、店舗・設備に関する情報が紙、Excel、Word、個人PC、サーバーなどに分散していることが課題になっていました。テナントの入れ替え時には、店舗にどのような設備があるのか、いつ更新されたのか、どの資料が最新版なのかを把握する必要があります。しかし、情報の所在や更新状況が分かりにくい状態では、必要な資料を探すだけでも時間がかかります。
そこで、約500店舗の設備データ、図面、工事費、議事録、行政への届出書類などをプリザンターへ移行し、Web上で一元管理できる環境づくりを進めました。
導入の結果、これまで各拠点や個人PCに散らばっていた「最新の設備情報」や「過去の修繕履歴」へ、関係者全員がアクセスできるようになりました。これにより、情報検索にかかっていた膨大な時間が大幅に削減され、テナント入れ替え時の対応スピード向上や、引き継ぎ・情報共有の効率化という確かな成果に繋がっています。
この事例は、複数店舗や複数施設の設備台帳を管理する企業にとって参考になるケースです。設備台帳を単なるExcelファイルとして保管するのではなく、関係者が同じ情報を参照できるWebデータベースとして整備することで、確認作業や情報共有の負担を減らしやすくなります。自社でも同じように、店舗・設備・図面・工事関連資料が複数の場所に分散している場合は、どのような手順で一元管理へ移行したのかを確認しておくと、導入後のイメージを持ちやすくなります。
➡約500店舗規模での設備データ一元管理事例を見る

まとめ

複数物件や商業施設の設備台帳をExcelだけで管理し続けると、テナント入れ替え時の確認負荷、法定点検の期限管理、修繕計画の把握、担当者への属人化、外部関係者との情報共有といった課題が表面化しやすくなります。FM・PM業務における設備台帳は、単なる一覧表ではなく、施設運営の安全性、業務効率、資産価値の維持を支える情報基盤です。だからこそ、設備情報、点検結果、図面、修繕履歴を分散させず、関係者が必要な情報にアクセスできる状態を整えることが重要です。まずは、現在の台帳・書類・図面・点検記録がどこに保管されているのかを棚卸しし、どの情報を優先的に一元管理すべきかを整理することから始めてみてください。そのうえで、Webデータベースやプリザンターを活用することで、Excelの使いやすさを活かしながら、FM・PM業務に適した管理体制を構築しやすくなります。運用の属人化を防ぐためにも、導入を検討している方はお気軽にご相談ください。

The post 商業施設の設備台帳管理をExcelで続ける限界とは？FM・PM業務を効率化する方法 first appeared on SMS DataTech.

この記事でわかること

• どの業務を効率化・自動化できるか
• AIやFAQを使った対応負荷の減らし方
• 標準化・自動化の進め方
• 守りの情シスから攻めの情シスへ変わる考え方
• ITアウトソーシングを活用する判断ポイント

なぜ情シス業務の効率化が必要なのか

情シスの仕事は、以前よりも複雑になっています。社内システムだけでなく、クラウドサービス、SaaS、リモートワーク環境、セキュリティ対策、生成AI活用など、対応すべき範囲が広がっているためです。一方で、情シスの人員が十分に増えている企業ばかりではありません。少人数の情シスが、問い合わせ対応、端末管理、アカウント管理、障害対応、社内調整まで担っているケースも多くあります。この状態が続くと、情シスは常に目の前の作業に追われます。結果として、業務改善やDX推進に時間を使えず、会社全体のIT活用も進みにくくなります。情シス業務の効率化は、担当者を楽にするだけではありません。会社全体の生産性を高めるための取り組みです。

情シス業務で効率化しやすい領域

情シス業務の中には、人が毎回対応しなくてもよい業務があります。特に、手順が決まっている作業や、同じ内容が繰り返される問い合わせは、効率化しやすい領域です。

まず取り組みやすいのは、問い合わせ対応の整理です。問い合わせ内容を確認すると、「パスワードを忘れた」「VPNにつながらない」「社内システムにログインできない」「共有フォルダにアクセスできない」といった、同じような質問が何度も発生していることがあります。

こうした問い合わせは、FAQや社内ナレッジとしてまとめることで、社員が自分で解決しやすくなります。さらにAI検索やチャットボットを組み合わせれば、情シス担当者が毎回手作業で回答する負担を減らせます。

生成AIを使った情シス業務効率化の具体例

生成AIは、情シス業務をすべて代わりに行うものではありません。ただし、文章作成、情報整理、手順書作成、問い合わせ対応の補助などでは大きな効果が期待できます。

• FAQ・問い合わせ対応の自動化
  「パスワードを忘れた」「Teamsにログインできない」といった問い合わせ内容をAIが整理し、チャットボットを活用することでお問い合わせ対応の自動化を行うことができます。
• SaaS・クラウドサービス導入時の情報整理
  ベンダー資料や設定マニュアルを要約させることで、「どの機能が重要か」「事前に何を確認すべきか」を短時間で把握しやすくなります。
• 定型業務のマニュアル化
  PCキッティングやアカウント発行などの作業メモをもとに、教育用マニュアルやチェックリストを作成できます。属人化防止や引き継ぎ効率化にもつながります。

生成AIは、情シス担当者の判断を置き換えるものではなく、作業時間を短縮する補助ツールとして使うのが現実的です。そのため、生成AIを活用したとしても「攻めの情シス」にはなりません。

守りの情シスから攻めの情シスへ変わるには

従来の情シスは、トラブル対応や社内ITの維持管理が中心でした。もちろん、これらは今でも重要です。しかし、AI時代の情シスには、会社全体の業務効率化を支える役割も求められています。

• 従来の情シス　＜守りが中心＞
  • トラブルが起きてから対応する
  • 問い合わせに人力で答える
  • 端末やアカウントを個別に管理する
  • IT運用を維持する
• これからの情シス　＜守りを固めながら攻めにも時間を使う＞
  • 問題が起きにくい仕組みを作る
  • FAQやAIで仕組み化し、問い合わせの発生を抑える
  • ルール化・標準化をしてミスを減らす
  • ITで業務改善を進める

攻めの情シスとは、新しいツールを入れるだけではありません。現場の業務を理解し、どこにムダがあるのか、どこを自動化すれば効果が出るのかを考え、会社全体の働き方を良くする情シスです。そのためには、まず日々の運用業務を整理し、負担の大きい作業から順番に効率化することが大切です。

情シス業務を効率化する進め方

情シス業務の効率化は、いきなり大規模なシステムを導入するよりも、現状把握から始めることが重要です。

1. 現状把握：問い合わせ件数、作業時間、属人化している業務を整理する
2. 優先順位付け：件数が多い業務、ミスが起きやすい業務から着手する
3. 標準化：手順書、申請ルール、対応フローを整える
4. 自動化：FAQ、チャットボット、ワークフロー、管理ツールを活用する
5. 見直し：効果を確認し、改善を続ける

最初に取り組むべきなのは、問い合わせ内容の整理です。問い合わせを分類するだけでも、どの業務に時間がかかっているかが見えてきます。次に、同じ作業が繰り返されている業務を標準化します。たとえば、入社時のアカウント作成、退職時の権限削除、PC貸与、SaaS申請などは、フローを決めることでミスや漏れを減らせます。そのうえで、FAQ、チャットボット、ワークフロー、端末管理ツールなどを活用すれば、情シス担当者の負担を段階的に減らせます。

AIやツールで効率化が進まない場合はITアウトソーシングも選択肢

AIやツールは便利ですが、導入しただけで業務が自動的に整理されるわけではありません。たとえば生成AIも、元となるFAQや手順、対応履歴が整理されていなければ十分に活用できません。また、ツール導入後も、アカウント管理・権限設定・問い合わせ対応・SaaS管理などの運用負荷は残り続けます。つまり、「ツールを導入すること」と「現場負荷が減ること」は必ずしも同じではないのです。

そのような場合は、ITアウトソーシングの活用も有効です。ITアウトソーシングを活用すると、ヘルプデスク、キッティング、端末管理、アカウント管理、SaaS管理、定型的な運用業務などを外部に任せることができます。これにより、社内の情シス担当者は、業務改善、DX推進、セキュリティ強化、AI活用の検討など、より重要な仕事に集中しやすくなります。特に、以下のような状況では、ITアウトソーシングが有効です。

• 情シス担当者が少人数
• AIやツールを活用できるほどデータの整理ができていない
• SaaSやシステムが増え続けている
• DXやAI活用を進める余裕がない
• 情シスが“なんでも屋”化している

ITアウトソーシングは、情シスの仕事をなくすものではありません。むしろ、情シスが本来やるべき価値の高い仕事に集中するための手段です。情シス業務の属人化をなくし、AI時代に合った効率的な運用体制を作る手段として、ITアウトソーシングを検討する企業も増えています。

SMSデータテックのITアウトソーシング

SMSデータテックのITアウトソーシングでは、ただ業務のアウトソーシングをするのではなく、現状把握として業務の整理から、代行サービス、サポート、引継ぎ対応、情シスの業務効率化や生成AI活用まで幅広いサービスを提供しています。貴社の一員となって小さな困りごとから会社全体の生産性向上までサポートいたします。「忙しすぎて具体的な悩みまで落とし込めない」という状況でも問題ありません。一緒に業務の整理から進めていきます。まずは小さなお悩みをご相談ください。

まとめ

AI時代の情シスには、すべての作業を自分たちで抱え込むのではなく、仕組みで効率化していくという考え方が必要です。 情シスの価値は、単にトラブルを処理することだけではありません。ITを使って会社全体の働き方を良くすることにあります。そのためには、日々の運用業務を軽くし、改善や企画に使える時間を作ることが欠かせません。生成AIを活用することで、問い合わせ対応やマニュアル作成、報告書作成などの補助に活用できます。自動化ツールやFAQ、ワークフローを組み合わせることで、日々の運用負荷を減らすこともできます。しかし、社内だけで改善が進まない場合は、ITアウトソーシングを活用することも有効です。現状の把握から業務整理を専門家と一緒に行うことで情シス業務だけでなく、DX推進、業務改善、IT戦略の立案といった攻めの業務もスムーズに進めることができます。AI時代の情シスに必要なのは、すべてを人力で抱え込むことではありません。仕組み化、自動化、外部活用によって、会社全体を支える働き方へ変えていくことです。情シス業務の属人化をなくし、AI時代に合った効率的な運用体制を作りたい方は、ITアウトソーシングの活用を検討してみてください。

The post 情シス業務を効率化・自動化するには？AI時代に求められる“攻めの情シス”の働き方 first appeared on SMS DataTech.

一方で、実際にAI導入を進めようとすると、「何から始めればよいかわからない」「ChatGPTなどを契約したものの、現場で使われていない」「社内ルールやセキュリティ面が不安」といった課題に直面する企業も少なくありません。

AIは、ツールを導入するだけで成果が出るものではありません。自社の業務課題を整理し、業務への落とし込みや社員研修、運用ルールの整備などを進める必要があります。しかし、これらをすべて社内だけで担うには、AI推進体制の整備や最新技術のキャッチアップ、現場への定着支援まで継続的に行う必要があり、負担が大きくなりがちです。

こうした課題を解決する手段として、AI導入を研修・コンサルティング・システム構築・定着支援の面から支援する会社やサービスが増えています。そこで本記事では、AI導入支援会社に依頼できることや選び方、おすすめのAI導入支援会社・サービス10選を紹介します。

AI 導入支援会社とは

AI導入支援会社とは、企業がAIを業務で活用できるように、導入前の課題整理から研修、システム構築、運用改善、社内定着までを支援する会社です。

AI導入というと、ChatGPTやAIチャットボット、AI議事録ツールなどを契約することをイメージする方もいるかもしれません。しかし、AIツールを契約しただけでは、業務改善につながらないケースもあります。

たとえば、生成AIを契約しても、社員が使い方を理解していなければ利用は広がりません。また、利用ルールが整備されていない状態では、機密情報や個人情報の取り扱いに不安が残ります。さらに、どの業務にAIを活用すべきかが曖昧なままでは、費用対効果も判断しづらくなります。AI導入支援会社は、こうした課題に対して、AI活用の方針策定、業務の洗い出し、社員研修、AIエージェントや業務システムの構築、導入後の改善などを支援します。

つまり、AI導入支援会社は、単にAIツールを紹介するのではなく、企業がAIを実務で使える状態にするための支援を行う会社だといえます。

AI 導入支援会社に依頼できること

AI導入支援会社に依頼できる内容は、会社によって異なります。主な支援内容は、AI活用方針の整理、社員向け研修、業務への落とし込み、AIシステムやAIエージェントの構築、導入後の運用改善などです。

特に、生成AIの業務活用では「どのツールを使うか」だけでなく、「どの業務にどう組み込むか」が重要になります。文章作成や議事録作成のような個人作業の効率化から、社内ナレッジ検索、問い合わせ対応、営業資料作成、データ分析、月次レポート作成など、AIを活用できる領域は多岐にわたります。

ただし、すべての業務に同じように効果が出るわけではありません。最初から大規模な開発を行うよりも、効果が見えやすい業務から小さく始め、現場の反応を見ながら広げていく進め方が現実的です。AI導入支援会社に相談することで、自社の業務内容や組織体制に合わせて、どこからAI活用を始めるべきかを整理しやすくなります。

AI 導入支援会社を選ぶ際のポイント

AI導入支援会社を選ぶ際に特に重要なのは、「自社の業務に合わせて、安全に・継続的に使われる状態まで支援できるか」です。知名度やサービス名だけで判断するのではなく、導入前の設計から現場定着、セキュリティ・運用改善まで伴走できるかを確認しましょう。

特に、以下の4点は事前に確認しておくとよいでしょう。

• 研修だけでなく、実務への落とし込みまで支援できるか
• 決められたパッケージではなく、自社業務に合わせて柔軟に設計・改善できるか
• 機密情報や個人情報の扱い、権限管理などセキュリティ面まで相談できるか
• 単発の導入支援ではなく、導入後の改善や運用定着まで長期的に支援できるか

AI導入支援会社といっても、得意領域は会社によって異なります。社員研修や人材育成に強い会社もあれば、AIエージェントやRAG構築などの実装に強い会社もあります。また、業務改革や組織変革とあわせてAI活用を支援する会社もあります。

「社員のAIリテラシーを高めたい」のか、「AIを使った業務システムを構築したい」のか、「まずは自社で何ができるか整理したい」のかによって、選ぶべき会社は変わります。

そのため、サービス名や機能だけで比較するのではなく、自社がAI導入で解決したい課題に対して、どこまで支援してもらえるのかを確認しましょう。

AI 導入支援会社おすすめ10選

ここからは、AI導入を検討している企業におすすめのAI導入支援会社・サービスを紹介します。

本記事では、単体のAIツールではなく、コンサルティング、研修、構築、定着支援などを提供している会社・サービスを中心に取り上げています。

1. デジライズ

デジライズは、AIリスキリングとコンサルティングを通じて、企業のAI活用を支援する会社です。

AIを一部の担当者だけで使うのではなく、組織全体に浸透させることを重視している点が特徴です。社員研修に加えて、実際の業務でAIをどう活用するかまで支援を受けられるため、AIを社内に定着させたい企業に向いています。

全社的にAI活用を広げたい企業や、研修と実装支援をまとめて依頼したい企業に適した選択肢です。AI導入を一時的な施策ではなく、組織全体の変化につなげたい場合に検討しやすい会社です。

2. キカガク

キカガクは、生成AI導入支援やAI人材育成に強みを持つ企業です。

生成AI搭載システムの開発支援に加えて、導入コンサルティングや研修などの導入後支援にも対応しています。AI導入を外部に任せきりにするのではなく、社内にAIを扱える人材を育てながら進めたい企業に向いています。

特に、将来的な内製化を見据えてAI活用を進めたい企業にとって、教育と実装をバランスよく相談しやすい会社です。AI活用の企画からPoC、開発、人材育成までを組み合わせて進めたい場合に適しています。

3. AVILEN

AVILENは、生成AI導入を上流から支援し、ビジネス活用を実現するためのサービスを提供しています。

生成AIの導入支援だけでなく、データ利活用できる組織づくりや、AI技術の企画・開発・導入にも対応している点が特徴です。社員教育とAIソリューションの両方に対応しているため、データ・AI活用を組織的に進めたい企業に向いています。

生成AIの活用だけでなく、データ分析や機械学習を含めたAI活用を検討している企業にも適しています。AI人材育成と実装を並行して進めたい場合に検討しやすい会社です。

4. スキルアップAI

スキルアップAIは、AI・DX人材育成を中心に、企業のAI活用力向上を支援する会社です。

人材育成計画の策定から評価、研修、実データを活用した課題解決型プログラム、AI開発・導入支援までを一貫して提供している点が特徴です。

AI導入の前段階として、まずは社員の理解度を高めたい企業や、部署ごとにAI活用力を底上げしたい企業に向いています。単なる座学ではなく、実務に近いテーマでAI活用を学ばせたい場合にも検討しやすい会社です。

5. JMAC

JMACは、製造業・サービス業を中心に、業務改善や組織改革、DXなどを支援するコンサルティングファームです。

生成AIを活用した組織変革プログラムを提供しており、AIを単なるツール導入ではなく、業務改革や経営課題の解決につなげたい企業に向いています。

特に、現場業務の改善や組織全体の変革とAI活用を結びつけたい企業に適しています。技術導入だけでなく、業務プロセスや組織のあり方まで見直したい場合に候補となる会社です。

6. パーソルワークスイッチコンサルティング

パーソルワークスイッチコンサルティングは、生成AI技術と業務プロセスの両方に精通したコンサルタントが、AIエージェントの業務実装を支援するサービスを提供しています。

特徴は、「どの業務をAIに任せ、どの業務を人間が担うか」の切り分けから、実装、検証、運用安定化まで支援している点です。導入済みのAIツールが現場に定着しないという課題に対しても、伴走型の定着化支援を行っています。

AIを単なるチャット利用にとどめず、業務プロセスの中に組み込みたい企業に向いています。AIエージェントの導入や、既存AIツールの活用定着に課題を感じている企業におすすめです。

7. Ridge-i

Ridge-iは、生成AIコンサルティング・開発サービスを提供するAI企業です。

生成AI活用に向けたDX戦略の構築から、AIシステムの設計・開発、オペレーション構築、人材育成までをワンストップで支援している点が特徴です。また、大規模言語モデルの研究開発やチューニング開発にも対応しています。

高度なAI活用や独自AI開発を検討している企業に向いており、生成AIを経営や業務に深く組み込みたい場合に候補となります。単なる研修やツール導入ではなく、戦略設計から開発まで踏み込んで相談したい企業に適しています。

8. Laboro.AI

Laboro.AIは、オーダーメイド型AIソリューション「カスタムAI」の開発・提供を行う会社です。

AI開発に先立つビジョンや戦略策定、導入ロードマップの策定、運用のためのコンサルティング支援にも対応している点が特徴です。汎用的なAIツールでは対応しづらい、自社固有の業務課題に合わせたAIを開発したい企業に向いています。

一方で、まずはAI研修や小規模な定着支援から始めたい企業よりも、具体的なAI開発テーマがある企業に適した会社です。独自AIモデルやAIエージェントを自社の業務に合わせて作り込みたい場合に検討しやすいサービスです。

9. 株式会社インディゴデータ

株式会社インディゴデータは、中小企業向けAI伴走支援サービス「ヒトタスAI」を提供する会社です。

特徴は、AI導入を「ツールを入れて終わり」にせず、現場で使われる状態まで支援する点にあります。AI初心者向けの研修・定着支援から、継続的にAI活用を相談できるAI伴走顧問、業務に合わせたAI構築・運用まで、企業の状況に合わせた支援を受けられます。

特に、ChatGPTなどを導入したものの現場で使われていない企業や、AIを使いたいが何から始めればよいかわからない企業に向いています。大規模なAI開発よりも、まずは身近な業務からAI活用を始め、効果を見ながら広げていきたい企業にとって相談しやすいサービスです。

また、Difyなどを活用した業務フロー自動化や、既存システムへのAI機能追加にも対応しているため、研修だけでなく実務への落とし込みまで支援を受けたい企業にも適しています。

10. 株式会社SMSデータテック

株式会社SMSデータテックは、働くAI「Claude Cowork」の導入から組織定着までを支援する「Claude Cowork内製化支援」を提供しています。

特徴は、AIを「質問に答えるもの」として使うだけでなく、実際の業務を進める「働くAI」として活用する点にあります。Claude Coworkは、PC上のファイルにアクセスし、依頼内容をもとにデータの読み取り、整理、分析などを行うことができます。

たとえば、営業データの整理、マーケティング施策の分析、月次レビュー資料の作成、会議資料のたたき台作成など、従来は人が手作業で行っていた業務の効率化が期待できます。

特に、生成AIやSaaS、RPAなどを導入したものの、業務全体の自動化や内製化につながっていない企業に向いています。単なるAIツールの導入ではなく、業務設計から運用定着まで支援を受けたい場合に検討しやすいサービスです。

また、SMSデータテックはシステム運用領域で25年の実績があり、業務効率化だけでなく、セキュリティや運用管理の観点を踏まえてAI活用を設計できる点も強みです。AIを安全に活用しながら、社内で運用できる状態まで整えたい企業に適しています。

AI 導入支援会社のタイプ別の選び方

AI導入支援会社は、大きく分けると「伴走支援・コンサル型」「研修・人材育成型」「開発・実装支援型」「AIエージェント内製化型」の4つに分類できます。

自社の課題がまだ明確でない場合は、まず伴走支援・コンサル型の会社に相談し、業務課題や導入方針を整理するところから始めるとよいでしょう。特に、現場で使われる状態まで支援してほしい場合は、単発の研修やパッケージ導入ではなく、継続的に改善できる支援体制があるかを確認することが大切です。

一方で、すでに「社内ナレッジ検索をAI化したい」「問い合わせ対応を自動化したい」「独自AIモデルを作りたい」といったテーマが明確な場合は、開発・実装支援型の会社が適しています。

また、生成AIを導入したものの、日々の業務削減につながっていない場合は、AIエージェント内製化型のサービスを検討するとよいでしょう。AIを単なるチャットツールとしてではなく、実務を進める存在として活用することで、より具体的な業務効率化につなげやすくなります。

AI 導入支援会社を選ぶ際の注意点

AI導入支援会社を選ぶ際は、目的が曖昧なまま依頼しないことが大切です。

「とりあえずAIを導入したい」という状態では、支援内容も抽象的になりやすく、導入後の成果を判断しづらくなります。問い合わせ対応を効率化したいのか、資料作成を効率化したいのか、社内ナレッジを検索しやすくしたいのか、社員のAIリテラシーを高めたいのかなど、まずは目的を整理しておきましょう。

また、AI研修だけで終わらせないことも重要です。研修はAI活用の第一歩ですが、研修を受けただけで業務が変わるとは限りません。実際の業務に合わせた活用例やプロンプトテンプレート、社内ルール、運用フローを整備することで、AI活用は定着しやすくなります。

セキュリティやガバナンスも後回しにしてはいけません。生成AIを業務で使う場合は、機密情報や個人情報の扱い、入力してよい情報の範囲、利用ログの管理、権限設定などを整理する必要があります。安全にAI活用を進めるためにも、運用ルールまで相談できる会社を選びましょう。

AI 導入を成功させる進め方

AI導入を成功させるには、段階的に進めることが重要です。

1. 現状業務と課題を整理する
2. AI化しやすい業務を選ぶ
3. 一部の部署や業務で小さく試す
4. 社内ルールや活用テンプレートを整備する
5. 利用状況を見ながら改善を続ける

まずは、どの業務に時間がかかっているのか、どの作業が属人化しているのか、どの業務でミスや手戻りが発生しやすいのかを確認します。そこから、AIで効率化しやすい業務を選び、一部の部署や特定業務で試すと、効果や課題を把握しやすくなります。

試験導入で効果が見えたら、AI利用ガイドラインや業務別プロンプト集、確認フロー、活用事例集などを整備します。社員が迷わずAIを使える状態を作ることで、AI活用は現場に定着しやすくなります。

導入後は、利用状況や現場の声をもとに改善を続けましょう。AI導入は一度設定して終わりではありません。業務の変化や利用状況に合わせて改善することで、継続的な業務改善につなげることができます。

ただし、これらをすべて自社だけで実施するには、AI推進室のような体制づくりや、最新技術・セキュリティ動向の継続的なキャッチアップが必要になります。AI技術は変化が速いため、準備に時間をかけすぎると、導入時点で活用方法が古くなってしまう可能性もあります。すべてを社内だけで抱え込まず、必要に応じてAI導入支援サービスを活用することも検討しましょう。

まとめ

AI導入支援会社は、企業がAIを業務で活用できるように、課題整理、研修、構築、運用改善、社内定着までを支援する存在です。

特に、AIを導入したいが何から始めればよいかわからない企業や、ChatGPTなどを導入したものの現場で活用が進んでいない企業は、AI導入支援会社への相談がおすすめです。

SMSデータテックではClaude Cowork内製化支援サービスを提供しています。システム運用で培ったセキュリティ・運用管理の知見を踏まえ、貴社の業務・体制に合わせたAI活用可能性と課題を無料診断で整理できますので、お気軽にお問い合わせください。

The post AI導入支援会社おすすめ10選！生成AI導入・内製化を成功させる選び方を解説 first appeared on SMS DataTech.

こんにちは！マーケターから未経験のエンジニアに転身した社員Tです。
開発を始めて1年が経ち、サーバーサイド開発にも触れるようになりました。
今回は、Javaを使用したダッシュボードAPIの作成についてご紹介します。
これまでフロントエンド中心の開発を行っていた私が、サーバーサイドのAPI開発に挑戦していく様子をお届けします。

本記事の対象の方

• サーバーサイド開発をこれから学びたい方
• JavaでのAPI開発に興味がある方
• ダッシュボードの作成を通じて、実践的な技術を学びたい方

Javaとは？

Javaは、非常に人気のあるオブジェクト指向プログラミング言語で、さまざまなアプリケーションの開発に広く使用されています。

詳しい説明については、過去のブログ記事をご参照ください。
⇒関連記事はこちら

環境構築

環境構築に関しては、内容が広範囲にわたるため、別の記事で詳細に解説する予定です。

ダッシュボードAPIの作成

今回作成したいのは、こんなダッシュボード画面です。ユーザーがコースを選択することで、自分の学習状況を一目で確認できるようにすることを目指しています。

全体の作成の流れとしては、下記の通りとなります。

1. ユーザー情報を取得
2. コース情報を取得
3. 各グラフ描画に必要なデータを取得

今回は、3.各グラフ描画に必要なデータを取得するAPIの実装について詳しく触れていきたいと思います。5つグラフがありますが、右下の同資格受験者との比較グラフを作成します。

1. ユーザー情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

2. コース情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

試験情報取得APIの設計

エンドポイント

/top/getScoreDistribution

• HTTPメソッド: POST
• リクエストボディ: ユーザーID、コースID
• レスポンス: 模擬試験のスコアリスト

リクエスト例

{
    "courseId":"7",
    "userId":"175"
}

今回はパスパラメータではなく、リクエストボディからユーザーIDとコースIDを受け取る設計にしています。これにより、柔軟なデータの受け渡しが可能となります。

レスポンス例

{
    "scoreDistribution": {
        "A": 5,
        "B": 3,
        "C": 2,
        "D": 10
    },
    "errorMessageList": null
}

試験情報取得APIの実装

モデルクラスの作成

模擬試験履歴を表すエンティティクラスを作成します。このクラスはデータベースの trial_exam_history テーブルに対応し、各試験の履歴情報を管理します。

 1package jp.co.smsdatatech.questiongenerate.entity;

 2 

 3import java.io.Serializable;

 4import lombok.Data;

 5 

 6/**

 7 * TrialExamHistoryテーブルEntity

 8 */

 9@Data

10public class TrialExamHistoryEntity implements Serializable {

11 

12    /** シリアルバージョンUID */

13    private static final long serialVersionUID = 1L;

14 

15    /** 試験履歴ID */

16    private Integer trialExamHistoryId;

17 

18    /** 試験ID */

19    private Integer trialExamId;

20 

21    /** 試験回数 */

22    private Integer trialExamTimes;

23 

24    /** 試験スコア */

25    private Integer trialScore;

26 

27    /** ユーザーID */

28    private Integer userId;

29}

MyBatisのMapper設定

このクエリでは、RANK() 関数を用いて、各ユーザーの試験履歴をスコアの降順でランク付けし、最も高いスコアの試験のみを取得しています。

 1<mapper namespace="jp.co.smsdatatech.questiongenerate.repository.TrialExamHistoryMapper">

 2 

 3    <select id="selectLatestTrialExamHistoryList" resultMap="TrialExamHistoryResultMap" resultType="jp.co.smsdatatech.questiongenerate.entity.TrialExamHistoryEntity">

 4        SELECT

 5            highest_score_exam.user_id,

 6            highest_score_exam.trial_exam_id,

 7            highest_score_exam.trial_exam_score,

 8            highest_score_exam.trial_exam_times

 9        FROM

10            (

11                SELECT

12                    teh.user_id,

13                    teh.trial_exam_id,

14                    teh.trial_exam_score,

15                    teh.trial_exam_times,

16                    RANK() OVER (PARTITION BY teh.user_id ORDER BY teh.trial_exam_score DESC, teh.trial_exam_times DESC) AS rank_num

17                FROM

18                    trial_exam_history teh

19                JOIN

20                    trial_exam AS exam

21                    ON teh.trial_exam_id = exam.trial_exam_id

22                WHERE

23                    exam.course_id = #{courseId}

24            ) AS highest_score_exam

25        WHERE

26            highest_score_exam.rank_num = 1;

27    </select>

28</mapper>

サービスクラスの作成

trialExamHistoryMapper.selectLatestTrialExamHistoryList(courseId) を呼び出し、試験履歴を取得します。

 1/**

 2 * 指定したコースIDに基づいて、複数ユーザーの最新試験履歴を取得する。

 3 *

 4 * @param courseId コースID

 5 * @return 最新の模擬試験履歴リスト

 6 */

 7@Transactional(readOnly = true)

 8public List<TrialExamHistoryEntity> selectLatestTrialExamHistoryList(Integer courseId) {

 9 

10    log.debug("コースID {} の最新の模擬試験履歴を取得します。", courseId);

11 

12    // データベースから複数ユーザーの最新試験履歴を取得

13    List<TrialExamHistoryEntity> latestTrialExamHistoryList = trialExamHistoryMapper

14            .selectLatestTrialExamHistoryList(courseId);

15 

16    log.debug("取得した複数ユーザーの最新模擬試験履歴リスト: {}", latestTrialExamHistoryList);

17 

18    return latestTrialExamHistoryList;

19}

コントローラークラスの作成

selectLatestTrialExamHistoryList(courseId) で最新の試験履歴を取得。取得した履歴データをもとに、スコア範囲ごとの人数をカウントし、レスポンスとして返却します。

 1/**

 2 * 最新の模擬試験履歴を取得（スコア範囲ごとの人数分布のみ返却）。

 3 *

 4 * <h3>機能概要</h3>

 5 * コースIDに基づいて、スコア範囲ごとの人数分布を取得する。

 6 *

 7 * <h3>処理フロー</h3>

 8 * 1. リクエストデータのバリデーション<br>

 9 * 2. サービスクラスを呼び出して、スコア範囲ごとの人数分布を取得<br>

10 * 3. スコア範囲ごとの人数分布が見つからない場合はエラーメッセージを設定<br>

11 * 4. スコア範囲ごとの人数分布を返却

12 *

13 * @param form    UserIdForm

14 * @param result  バリデーション結果やエラーを格納

15 * @return スコア範囲ごとの人数分布 ScoreDistributionResponseForm

16 */

17@PostMapping("/top/getScoreDistribution")

18public ScoreDistributionResponseForm getScoreDistribution(

19        @RequestBody @Validated({ ValidationGroups.Step1.class, ValidationGroups.Step2.class }) UserIdForm form,

20        BindingResult result) {

21    log.debug("TopRest (getScoreDistribution) 呼び出し開始");

22 

23    ScoreDistributionResponseForm responseForm = new ScoreDistributionResponseForm();

24    List<String> errorMessageList = new ArrayList<>();

25 

26    // バリデーションエラーがある場合、詳細なエラーメッセージを追加

27    if (result.hasErrors()) {

28        for (FieldError fieldError : result.getFieldErrors()) {

29            String errorMessage = messageSource.getMessage(fieldError, Locale.getDefault());

30            errorMessageList.add(errorMessage);

31        }

32        responseForm.setErrorMessageList(errorMessageList);

33        return responseForm;

34    }

35 

36    Integer courseId = form.getCourseId();

37 

38    // 最新の模擬試験履歴リストを取得

39    List<TrialExamHistoryEntity> latestTrialExamHistoryList = trialExamHistoryService

40            .selectLatestTrialExamHistoryList(courseId);

41 

42    // リストが取得できなかった場合

43    if (CollectionUtils.isEmpty(latestTrialExamHistoryList)) {

44        errorMessageList

45                .add(messageSource.getMessage(ErrorMessages.TRIAL_EXAM_HISTORY_NOT_FOUND, null,

46                        Locale.getDefault()));

47        responseForm.setErrorMessageList(errorMessageList);

48        log.debug("最新の模擬試験履歴が見つかりませんでした");

49        return responseForm;

50    }

51 

52    // スコア範囲ごとの人数をカウントする

53    Map<String, Integer> scoreDistribution = new HashMap<>();

54    for (TrialExamHistoryEntity history : latestTrialExamHistoryList) {

55        int score = history.getTrialScore();

56        ScoreEnum range = ScoreEnum.getRange(score);

57        if (range != null) {

58            // スコア範囲に該当する人数を取り出し、1を加算する

59            int currentCount = scoreDistribution.getOrDefault(range.name(), 0);

60            scoreDistribution.put(range.name(), currentCount + 1);

61        }

62    }

63 

64    // スコア分布をResponseFormにセット

65    responseForm.setScoreDistribution(scoreDistribution);

66 

67    log.debug("TopRest (getScoreDistribution) 呼び出し終了");

68 

69    return responseForm;

70}

Enumクラスの作成

今回は、試験のスコア範囲を管理するために ScoreEnum を作成しました。スコアがどのランク（A, B, C, D）に属するかを判定するために使います。

 1package jp.co.smsdatatech.questiongenerate.enums;

 2 

 3import lombok.Getter;

 4 

 5/**

 6 * スコア範囲を表す列挙型クラス。

 7 *

 8 * <p>

 9 * 各範囲はスコアの最小値と最大値によって定義されます。

10 * スコアを基に適切なスコア範囲を判定する機能を提供します。

11 * </p>

12 */

13@Getter

14public enum ScoreEnum {

15    A(90, 100),  // A範囲：90〜100

16    B(80, 89),   // B範囲：80〜89

17    C(70, 79),   // C範囲：70〜79

18    D(0, 69);    // D範囲：0〜69

19 

20    private final int minScore;

21    private final int maxScore;

22 

23    // コンストラクタ

24    ScoreEnum(int minScore, int maxScore) {

25        this.minScore = minScore;

26        this.maxScore = maxScore;

27    }

28 

29    // スコアがこの範囲に含まれるかどうかをチェック

30    public boolean isInRange(int score) {

31        return score >= minScore && score <= maxScore;

32    }

33}

実装内容の振り返り

今回の実装では、SQLのRANK()関数とENUMクラスを活用して、ダッシュボード画面のデータ集計を効率的に行いました。

1. SQLの RANK() 関数について

RANK()関数は、特定の条件でデータを順位付けするために使用しました。RANK()を活用することで、プログラム側でループを回して順位を計算する必要がなくなり、SQLだけで効率的にデータを取得できるようになりました。

2. ENUMクラス ScoreEnum について

ScoreEnumは、スコアをランク（A, B, C, D）に分類するために作成しました。ENUMを使うことで、スコアの評価ロジックを統一し、可読性を向上させることができました。また、メソッドを定義することで、スコアがどのランクに属するかを簡単に判定できるようになり、コードの保守性も向上しました。

まとめ

今回のブログ記事を通して、ダッシュボード画面のすべての実装が完了しました。まだまだ改善の余地はあるかと思いますが、より良い書き方を模索しながら、さらに保守性や拡張性の高い実装を目指していきたいと思います。
長らく見ていただいてありがとうございました。次回は、テストやデータベース操作について、自身の学びをまとめていきたいと思います。

The post 【はじめてのJava】ダッシュボードAPIを作成しよう！⑦試験結果分布グラフ編【完結】 first appeared on SMS DataTech.

こんにちは！マーケターから未経験のエンジニアに転身した社員Tです。
開発を始めて1年が経ち、サーバーサイド開発にも触れるようになりました。
今回は、Javaを使用したダッシュボードAPIの作成についてご紹介します。
これまでフロントエンド中心の開発を行っていた私が、サーバーサイドのAPI開発に挑戦していく様子をお届けします。

本記事の対象の方

• サーバーサイド開発をこれから学びたい方
• JavaでのAPI開発に興味がある方
• ダッシュボードの作成を通じて、実践的な技術を学びたい方

Javaとは？

Javaは、非常に人気のあるオブジェクト指向プログラミング言語で、さまざまなアプリケーションの開発に広く使用されています。

詳しい説明については、過去のブログ記事をご参照ください。
⇒関連記事はこちら

環境構築

環境構築に関しては、内容が広範囲にわたるため、別の記事で詳細に解説する予定です。

ダッシュボードAPIの作成

今回作成したいのは、こんなダッシュボード画面です。ユーザーがコースを選択することで、自分の学習状況を一目で確認できるようにすることを目指しています。

全体の作成の流れとしては、下記の通りとなります。

1. ユーザー情報を取得
2. コース情報を取得
3. 各グラフ描画に必要なデータを取得

今回は、3.各グラフ描画に必要なデータを取得するAPIの実装について詳しく触れていきたいと思います。5つグラフがありますが、左下のスコア遷移表の制作に取り掛かりたいと思います。

1. ユーザー情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

2. コース情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

試験情報取得APIの設計

エンドポイント

/top/getTrialExamHistory

• HTTPメソッド: POST
• リクエストボディ: ユーザーID、コースID
• レスポンス: 模擬試験のスコアリスト

リクエスト例

{
    "courseId":"7",
    "userId":"175"
}

今回はパスパラメータではなく、リクエストボディからユーザーIDとコースIDを受け取る設計にしています。これにより、柔軟なデータの受け渡しが可能となります。

レスポンス例

{
    "trialExamHistoryList": [
        {
            "trialExamHistoryId": 63,
            "trialExamId": 1,
            "trialExamTimes": 5,
            "trialScore": 90,
            "userId": null
        },
        {
            "trialExamHistoryId": 69,
            "trialExamId": 1,
            "trialExamTimes": 2,
            "trialScore": 75,
            "userId": null
        },
        {
            "trialExamHistoryId": 72,
            "trialExamId": 1,
            "trialExamTimes": 1,
            "trialScore": 70,
            "userId": null
        }
    ],
    "errorMessageList": null
}

試験情報取得APIの実装

モデルクラスの作成

模擬試験履歴を表すエンティティクラスを作成します。このクラスはデータベースの trial_exam_history テーブルに対応し、各試験の履歴情報を管理します。

 1package jp.co.smsdatatech.questiongenerate.entity;

 2 

 3import java.io.Serializable;

 4import lombok.Data;

 5 

 6/**

 7 * TrialExamHistoryテーブルEntity

 8 */

 9@Data

10public class TrialExamHistoryEntity implements Serializable {

11 

12    /** シリアルバージョンUID */

13    private static final long serialVersionUID = 1L;

14 

15    /** 試験履歴ID */

16    private Integer trialExamHistoryId;

17 

18    /** 試験ID */

19    private Integer trialExamId;

20 

21    /** 試験回数 */

22    private Integer trialExamTimes;

23 

24    /** 試験スコア */

25    private Integer trialScore;

26 

27    /** ユーザーID */

28    private Integer userId;

29}

MyBatisのMapper設定

MyBatisのMapperインターフェースを定義し、模擬試験履歴を取得するメソッドを宣言します。指定されたユーザーIDとコースIDに基づいて直近5回分の模擬試験履歴を取得しています。

 1package jp.co.smsdatatech.questiongenerate.repository;

 2 

 3import java.util.List;

 4import org.apache.ibatis.annotations.Mapper;

 5import org.apache.ibatis.annotations.Param;

 6 

 7import jp.co.smsdatatech.questiongenerate.entity.TrialExamHistoryEntity;

 8 

 9/**

10 * TrialExamHistoryテーブルMapper

11 */

12@Mapper

13public interface TrialExamHistoryMapper {

14 

15    /**

16     * 指定されたユーザーID、コースIDに基づいて直近5回分の模擬試験履歴を取得する。

17     *

18     * @param userId   ユーザーID

19     * @param courseId コースID

20     * @return 模擬試験スコアリスト

21     */

22    List<TrialExamHistoryEntity> selectTrialExamHistoryList(

23            @Param("userId") Integer userId,

24            @Param("courseId") Integer courseId);

25 

26    /**

27     * 指定したコースIDに基づいて、複数ユーザーの最新試験履歴を取得します。

28     *

29     * @param courseId コースID

30     * @return 最新の試験履歴リスト（各ユーザー1件）

31     */

32    List<TrialExamHistoryEntity> selectLatestTrialExamHistoryList(

33            @Param("courseId") Integer courseId);

34}

サービスクラスの作成

次に、サービス層でデータベースから直近5回分の模擬試験履歴を取得するメソッドを実装します。このメソッドは、ユーザーIDとコースIDをもとに、模擬試験履歴をデータベースから取得します。

 1/**

 2 * 模擬試験履歴リスト作成Service

 3 */

 4@Slf4j

 5@Service

 6public class TrialExamHistoryService {

 7 

 8    private final TrialExamHistoryMapper trialExamHistoryMapper;

 9 

10    // コンストラクタインジェクションを使用

11    @Autowired

12    public TrialExamHistoryService(TrialExamHistoryMapper trialExamHistoryMapper) {

13        this.trialExamHistoryMapper = trialExamHistoryMapper;

14    }

15 

16    /**

17     * 指定されたユーザーID、コースIDに基づいて直近5回分の模擬試験履歴を取得する。

18     *

19     * @param userId   ユーザーID

20     * @param courseId コースID

21     * @return 模擬試験履歴リスト

22     */

23    @Transactional(readOnly = true)

24    public List<TrialExamHistoryEntity> selectTrialExamHistoryList(Integer userId, Integer courseId) {

25 

26        log.debug("ユーザーID {} のコースID {} の模擬試験履歴を取得します。", userId, courseId);

27 

28        // データベースから模擬試験履歴を取得

29        List<TrialExamHistoryEntity> trialExamHistoryList = trialExamHistoryMapper.selectTrialExamHistoryList(userId, courseId);

30        log.debug("取得した模擬試験履歴リスト: {}", trialExamHistoryList);

31 

32        return trialExamHistoryList;

33    }

34}

コントローラークラスの作成

@PostMapping アノテーションを使って、/top/getTrialExamHistory というエンドポイントを定義します。このエンドポイントは、ユーザーIDとコースIDを含むフォームを受け取り、バリデーションエラーがあればエラーメッセージを返します。

 1/**

 2 * 模擬試験履歴を取得.

 3 *

 4 * <h3>機能概要</h3>

 5 * ユーザーIDおよびコースIDに基づいて、模擬試験履歴を取得する。

 6 *

 7 * <h3>処理フロー</h3>

 8 * 1. リクエストデータのバリデーション<br>

 9 * 2. サービスクラスを呼び出して、模擬試験履歴を取得<br>

10 * 3. 履歴が見つからない場合はエラーメッセージを設定<br>

11 * 4. 模擬試験履歴またはエラーメッセージリストを返却

12 *

13 * @param form    ユーザーIDとコースIDのリクエストフォーム

14 * @param result  バリデーション結果やエラーを格納

15 * @return 模擬試験履歴リスト TrialExamHistoryResponseForm

16 */

17@PostMapping("/top/getTrialExamHistory")

18public TrialExamHistoryResponseForm getTrialExamHistory(

19        @RequestBody @Validated({ ValidationGroups.Step1.class, ValidationGroups.Step2.class }) UserIdForm form,

20        BindingResult result) {

21    log.debug("TrialExamHistoryRest (getTrialExamHistory) 呼び出し開始");

22 

23    TrialExamHistoryResponseForm responseForm = new TrialExamHistoryResponseForm();

24    List<String> errorMessageList = new ArrayList<>();

25 

26    // バリデーションエラーがある場合、詳細なエラーメッセージを追加

27    if (result.hasErrors()) {

28        for (FieldError fieldError : result.getFieldErrors()) {

29            String errorMessage = messageSource.getMessage(fieldError, Locale.getDefault()); // Localeを指定

30            errorMessageList.add(errorMessage);

31        }

32        responseForm.setErrorMessageList(errorMessageList);

33        return responseForm;

34    }

35 

36    Integer userId = Integer.parseInt(form.getUserId());

37    Integer courseId = form.getCourseId();

38 

39    // 模擬試験履歴リストを取得

40    List<TrialExamHistoryEntity> trialExamHistoryList = trialExamHistoryService.selectTrialExamHistoryList(userId,

41            courseId);

42 

43    // リストが取得できなかった場合

44    if (CollectionUtils.isEmpty(trialExamHistoryList)) {

45        errorMessageList

46                .add(messageSource.getMessage(ErrorMessages.TRIAL_EXAM_HISTORY_NOT_FOUND, null,

47                        Locale.getDefault()));

48        responseForm.setErrorMessageList(errorMessageList);

49        log.debug("模擬試験履歴が見つかりませんでした");

50        return responseForm;

51    }

52 

53    responseForm.setTrialExamHistoryList(trialExamHistoryList);

54    log.debug("TrialExamHistoryRest (getTrialExamHistory) 呼び出し終了");

55 

56    return responseForm;

57}

実装内容の振り返り

今回はシンプルに直近5回分の試験履歴を取得する実装でしたが、今後はキャッシュの活用や、SQLクエリ内で全件取得後に絞り込むのではなく、最初から直近5回分だけを取得するように修正することで、データベースへの負荷を軽減でき、より実用的に利用できるようになると感じました。

まとめ

シンプルな実装ではありましたが、SQLの書き方やキャッシュの導入余地など改善点も見えてきました。今後はパフォーマンスを意識した設計を取り入れ、より実用的なAPIに仕上げていきたいと思います。

The post 【はじめてのJava】ダッシュボードAPIを作成しよう！⑥試験回数遷移グラフ編 first appeared on SMS DataTech.

こんにちは！マーケターから未経験のエンジニアに転身した社員Tです。
開発を始めて1年が経ち、サーバーサイド開発にも触れるようになりました。
今回は、Javaを使用したダッシュボードAPIの作成についてご紹介します。
これまでフロントエンド中心の開発を行っていた私が、サーバーサイドのAPI開発に挑戦していく様子をお届けします。

本記事の対象の方

• サーバーサイド開発をこれから学びたい方
• JavaでのAPI開発に興味がある方
• ダッシュボードの作成を通じて、実践的な技術を学びたい方

Javaとは？

Javaは、非常に人気のあるオブジェクト指向プログラミング言語で、さまざまなアプリケーションの開発に広く使用されています。

詳しい説明については、過去のブログ記事をご参照ください。
⇒関連記事はこちら

環境構築

環境構築に関しては、内容が広範囲にわたるため、別の記事で詳細に解説する予定です。

ダッシュボードAPIの作成

今回作成したいのは、こんなダッシュボード画面です。ユーザーがコースを選択することで、自分の学習状況を一目で確認できるようにすることを目指しています。

全体の作成の流れとしては、下記の通りとなります。

1. ユーザー情報を取得
2. コース情報を取得
3. 各グラフ描画に必要なデータを取得

今回は、3.各グラフ描画に必要なデータを取得するAPIの実装について詳しく触れていきたいと思います。5つグラフがありますが、右上の各分野別の習得状況の表の制作に取り掛かりたいと思います。

1. ユーザー情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

2. コース情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

分野別進捗データ取得APIの設計

エンドポイント

/top/getViewHistory

• HTTPメソッド: POST
• リクエストボディ: ユーザーID、コースID
• レスポンス: 分野別の進捗率のリスト

リクエスト例

{
    "courseId":"7",
    "userId":"175"
}

今回はパスパラメータではなく、リクエストボディからユーザーIDとコースIDを受け取る設計にしています。これにより、柔軟なデータの受け渡しが可能となります。

レスポンス例

{
    "viewHistoryList": [
        {
            "fieldId": 1,
            "fieldName": "Javaの基礎",
            "fieldMaxProgress": 30.00
        },
        {
            "fieldId": 2,
            "fieldName": "Javaオブジェクト指向",
            "fieldMaxProgress": 40.00
        }
    ],
    "errorMessageList": null
}

分野別進捗データAPIの実装

モデルクラスの作成

ViewHistoryテーブルに対応するEntityクラスを作成します。Lombokを利用しており、getter、setter、toString 等を自動生成します。

 1package jp.co.smsdatatech.questiongenerate.entity;

 2 

 3import java.io.Serializable;

 4import java.math.BigDecimal;

 5 

 6import lombok.Data;

 7 

 8/**

 9 *

10 * ViewHistoryテーブルEntity

11 */

12@Data

13public class ViewHistoryEntity implements Serializable {

14 

15    /** シリアルバージョンUID */

16    private static final long serialVersionUID = 1L;

17 

18    /** 分野ID */

19    private Integer fieldId;

20 

21    /** 分野名 */

22    private String fieldName;

23 

24    /** 最大進捗率（集計結果） */

25    private BigDecimal fieldMaxProgress;

26}

MyBatisのMapper設定

MyBatis を使用して view_history テーブルからデータを取得する SQL マッピングを定義します。

 1<?xml version="1.0" encoding="UTF-8"?>

 2<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

 3<mapper namespace="jp.co.smsdatatech.questiongenerate.repository.ViewHistoryMapper">

 4 

 5    <select id="getViewHistoryWithMaxProgress" resultMap="ViewHistoryResultMap">

 6        SELECT

 7            subquery.course_id,

 8            subquery.field_id,

 9            subquery.fieldMaxProgress,

10            f.field_name

11        FROM

12            (SELECT

13                vh.course_id,

14                vh.field_id,

15                MAX(vh.progress_percentage) AS fieldMaxProgress

16            FROM

17                view_history vh

18            WHERE

19                vh.user_id = #{userId}

20                AND vh.course_id = #{courseId}

21                AND vh.viewed_at BETWEEN #{startOfWeek} AND #{endOfWeek}

22            GROUP BY

23                vh.course_id, vh.field_id) AS subquery

24        INNER JOIN

25            fields f

26        ON

27            subquery.field_id = f.field_id;

28    </select>

29</mapper>

サービスクラスの作成

Service層でDBからデータを取得する処理を実装します。

 1/**

 2 * 学習履歴リスト作成Service

 3 */

 4@Slf4j

 5@Service

 6public class ViewHistoryService {

 7 

 8    private final ViewHistoryMapper viewHistoryMapper;

 9 

10    // コンストラクタインジェクションを使用

11    @Autowired

12    public ViewHistoryService(ViewHistoryMapper viewHistoryMapper) {

13        this.viewHistoryMapper = viewHistoryMapper;

14    }

15 

16    /**

17     * 指定されたユーザーID、コースID、期間に基づいて分野別に最大進捗率を取得する。

18     *

19     * @param userId   ユーザーID

20     * @param courseId コースID

21     * @return 学習履歴（分野別に最大進捗率）のリスト

22     */

23    @Transactional(readOnly = true)

24    public List<ViewHistoryEntity> getViewHistoryWithMaxProgress(Integer userId, Integer courseId) {

25        // 週の開始日と終了日を計算

26        LocalDateTime startOfWeek = DateUtils.getStartOfWeek();

27        LocalDateTime endOfWeek = DateUtils.getEndOfWeek();

28 

29        log.debug("ユーザーID {} のコースID {} の学習履歴と最大進捗率を週の範囲 {} - {} で取得します。", userId, courseId, startOfWeek, endOfWeek);

30 

31        // データベースから分野別の最大進捗率を直接返す

32        return viewHistoryMapper.getViewHistoryWithMaxProgress(userId, courseId, startOfWeek, endOfWeek);

33    }

34}

コントローラークラスの作成

@PostMapping を使用してエンドポイント /top/getViewHistory を提供します。リクエストのバリデーションを行い、最大進捗率を返します。

 1/**

 2 * 分野別の最大進捗率を取得.

 3 * <h3>機能概要</h3>

 4 * ユーザーIDおよびコースIDに基づいて分野別の最大進捗率を取得し、ViewHistoryResponseFormに詰めて返却する。

 5 *

 6 * <h3>処理フロー</h3>

 7 * 1. リクエストデータのバリデーション<br>

 8 * 2. サービスクラスを呼び出して、最大進捗率を取得<br>

 9 * 3. 進捗率が見つからない場合はエラーメッセージを設定<br>

10 * 4. 最大進捗率またはエラーメッセージリストを返却

11 *

12 * @param form    UserIdForm

13 * @param result  バリデーション結果やエラーを格納

14 * @return 最大進捗率リスト ViewHistoryResponseForm

15 */

16@PostMapping("/top/getViewHistory")

17public ViewHistoryResponseForm getViewHistory(

18        @RequestBody @Validated({ ValidationGroups.Step1.class, ValidationGroups.Step2.class }) UserIdForm form,

19        BindingResult result) {

20    log.debug("TopRest (getViewHistory) 呼び出し開始");

21 

22    ViewHistoryResponseForm responseForm = new ViewHistoryResponseForm();

23    List<String> errorMessageList = new ArrayList<>();

24 

25    // バリデーションエラーがある場合、詳細なエラーメッセージを追加

26    if (result.hasErrors()) {

27        for (FieldError fieldError : result.getFieldErrors()) {

28            String errorMessage = messageSource.getMessage(fieldError, Locale.getDefault());

29            errorMessageList.add(errorMessage);

30        }

31        responseForm.setErrorMessageList(errorMessageList);

32        return responseForm;

33    }

34 

35    Integer userId = Integer.parseInt(form.getUserId());

36    Integer courseId = form.getCourseId();

37 

38    // 最大進捗率のリストを取得

39    List<ViewHistoryEntity> viewHistoryList = viewHistoryService.getViewHistoryWithMaxProgress(userId, courseId);

40 

41    // リストが取得できなかった場合

42    if (CollectionUtils.isEmpty(viewHistoryList)) {

43        errorMessageList

44                .add(messageSource.getMessage(ErrorMessages.VIEW_HISTORY_NOT_FOUND, null, Locale.getDefault()));

45        responseForm.setErrorMessageList(errorMessageList);

46        log.debug("ViewHistoryList (viewHistoryList) 学習履歴が見つかりません: ");

47        return responseForm;

48    }

49    responseForm.setViewHistoryList(viewHistoryList);

50    log.debug("TopRest (getViewHistory) 呼び出し終了");

51 

52    return responseForm;

53}

実装内容の振り返り

バリデーショングループを作成した点は新たな学びがありました。これまで単一のバリデーションルールを適用していましたが、バリデーショングループを導入することで、処理ごとに異なるバリデーションルールを適用できるようになりました。たとえば、新規登録時と更新時で必須項目を変える必要があるケースに対応しやすくなりました。

さらに、SQL の部分では INNER JOIN を活用し、効率的にデータを取得できるようにしました。view_history テーブルから最新の進捗データを取得し、fields テーブルと結合することで、分野名を含めた結果を一度のクエリで取得できるようになりました。

まとめ

今回の実装を通じて、バリデーションの柔軟な適用方法や共通部品の活用によるコードの整理、SQL の最適化といった学びを得ることができました。今後も、より効率的なコード設計を意識しながら開発を進めていきたいと思います。

The post 【はじめてのJava】ダッシュボードAPIを作成しよう！⑤分野別進捗データ取得編 first appeared on SMS DataTech.

こんにちは！マーケターから未経験のエンジニアに転身した社員Tです。
開発を始めて1年が経ち、サーバーサイド開発にも触れるようになりました。
今回は、Javaを使用したダッシュボードAPIの作成についてご紹介します。
これまでフロントエンド中心の開発を行っていた私が、サーバーサイドのAPI開発に挑戦していく様子をお届けします。

本記事の対象の方

• サーバーサイド開発をこれから学びたい方
• JavaでのAPI開発に興味がある方
• ダッシュボードの作成を通じて、実践的な技術を学びたい方

Javaとは？

Javaは、非常に人気のあるオブジェクト指向プログラミング言語で、さまざまなアプリケーションの開発に広く使用されています。

詳しい説明については、過去のブログ記事をご参照ください。
⇒過去のブログ一覧

環境構築

環境構築に関しては、内容が広範囲にわたるため、別の記事で詳細に解説する予定です。

ダッシュボードAPIの作成

今回作成したいのは、こんなダッシュボード画面です。ユーザーがコースを選択することで、自分の学習状況を一目で確認できるようにすることを目指しています。

全体の作成の流れとしては、下記の通りとなります。

1. ユーザー情報を取得
2. コース情報を取得
3. 各グラフ描画に必要なデータを取得

今回は、3.各グラフ描画に必要なデータを取得するAPIの実装について詳しく触れていきたいと思います。5つグラフがありますが、上段真ん中の総学習時間円グラフの制作に取り掛かりたいと思います。

1. ユーザー情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

2. コース情報の取得については、過去のブログ記事をご参考ください。
⇒関連記事はこちら

総学習時間取得APIの設計

エンドポイント

/top/getLoginHistoryByUserId

• HTTPメソッド: POST
• リクエストボディ: ユーザーID、コースID
• レスポンス: 総学習時間

リクエスト例

{
    "courseId":"7",
    "userId":"175"
}

今回はパスパラメータではなく、リクエストボディからユーザーIDとコースIDを受け取る設計にしています。これにより、柔軟なデータの受け渡しが可能となります。

レスポンス例

{
  "totalLearningTime": 0,
  "errorMessageList": null
}

総学習時間APIの実装

モデルクラスの作成

まず、ExerciseRecords テーブルに対応するエンティティクラスを定義します。このクラスは、データベースから取得した学習記録の情報を保持します。

 1package jp.co.smsdatatech.questiongenerate.entity;

 2 

 3import java.io.Serializable;

 4import java.sql.Timestamp;

 5import lombok.Data;

 6 

 7/**

 8 *

 9 * ExerciseRecordsテーブルEntity

10 */

11@Data

12public class ExerciseRecordsEntity implements Serializable {

13    /** シリアルバージョンUID */

14    private static final long serialVersionUID = 1L;

15 

16    /** ユーザーID */

17    private Integer userId;

18 

19    /** コースID */

20    private Integer courseId;

21 

22    /** 演習開始日時 */

23    private Timestamp startDate;

24 

25    /** 作成日 */

26    private Timestamp createDate;

27 

28    /** 更新日 */

29    private Timestamp updateDate;

30}

MyBatisのMapper設定

ExerciseRecordsMapper では、SQLを定義して、学習時間を合計します。EXTRACT(EPOCH FROM (end_time – start_time)) を使って学習時間を計算し、その結果を合計して返します。

 1<?xml version="1.0" encoding="UTF-8"?>

 2<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

 3<mapper namespace="jp.co.smsdatatech.questiongenerate.repository.ExerciseRecordsMapper">

 4    <select id="getTotalLearning" resultType="java.math.BigDecimal">

 5        SELECT

 6            SUM(EXTRACT(EPOCH FROM (end_time - start_time)) / 3600) AS totalLearningTime

 7        FROM

 8            exercise_records

 9        WHERE

10            user_id = #{userId}

11            AND course_id = #{courseId}

12            AND start_time BETWEEN #{startOfWeek} AND #{endOfWeek}

13    </select>

14</mapper>

サービスクラスの作成

次に、学習時間を取得するためのサービスクラスを作成します。ここでは、getTotalLearningTime メソッドを定義して、週の開始日と終了日を計算し、その範囲内での学習時間を集計します。

 1import lombok.extern.slf4j.Slf4j;

 2 

 3/**

 4 * 演習履歴テーブルService

 5 */

 6@Slf4j

 7@Service

 8public class ExerciseRecordsService {

 9 

10    private final ExerciseRecordsMapper exerciseRecordsMapper;

11 

12    // コンストラクタインジェクションを使用

13    @Autowired

14    public ExerciseRecordsService(ExerciseRecordsMapper exerciseRecordsMapper) {

15        this.exerciseRecordsMapper = exerciseRecordsMapper;

16    }

17 

18    /**

19     * ユーザーIDとコースIDを基に、週の範囲内で合計学習時間を取得する。

20     *

21     * @param userId   ユーザーID

22     * @param courseId コースID

23     * @return 総学習時間

24     */

25    @Transactional(readOnly = true)

26    public BigDecimal getTotalLearningTime(Integer userId, Integer courseId) {

27 

28        // 週の開始日と終了日を計算

29        LocalDateTime startOfWeek = DateUtils.getStartOfWeek();

30        LocalDateTime endOfWeek = DateUtils.getEndOfWeek();

31 

32        log.debug("ユーザーID {} とコースID {} の合計学習時間を週の範囲 {} - {} で取得します。", userId, courseId, startOfWeek, endOfWeek);

33        return exerciseRecordsMapper.getTotalLearning(userId, courseId, startOfWeek, endOfWeek);

34    }

35}

コントローラークラスの作成

次に、Spring BootのRESTコントローラを作成し、getTotalLearningTime メソッドを呼び出して、クライアントに学習時間を返却します。

 1/**

 2 * 総学習時間を取得.

 3 * <h3>機能概要</h3>

 4 * ユーザーIDおよびコースIDに基づいて総学習時間を取得し、TotalLearningTimeResponseFormに詰めて返却する。

 5 *

 6 * <h3>処理フロー</h3>

 7 * 1. リクエストデータのバリデーション<br>

 8 * 2. サービスクラスを呼び出して、総学習時間を取得<br>

 9 * 3. 学習時間が見つからない場合はエラーメッセージを設定<br>

10 * 4. 総学習時間またはエラーメッセージリストを返却

11 *

12 * @param form    UserIdForm

13 * @param result  バリデーション結果やエラーを格納

14 * @return 総学習時間リスト TotalLearningTimeResponseForm

15 */

16@PostMapping("/top/getTotalLearningTime")

17public TotalLearningTimeResponseForm getTotalLearningTime(

18        @RequestBody @Validated({ ValidationGroups.Step1.class, ValidationGroups.Step2.class }) UserIdForm form,

19        BindingResult result) {

20    log.debug("TopRest (getTotalLearningTime) 呼び出し開始");

21 

22    TotalLearningTimeResponseForm responseForm = new TotalLearningTimeResponseForm();

23    List<String> errorMessageList = new ArrayList<>();

24 

25    // バリデーションエラーがある場合、詳細なエラーメッセージを追加

26    if (result.hasErrors()) {

27        for (FieldError fieldError : result.getFieldErrors()) {

28            String errorMessage = messageSource.getMessage(fieldError, Locale.getDefault());

29            errorMessageList.add(errorMessage);

30        }

31        responseForm.setErrorMessageList(errorMessageList);

32        return responseForm;

33    }

34 

35    Integer userId = Integer.parseInt(form.getUserId());

36    Integer courseId = form.getCourseId();

37 

38    // サービスで合計学習時間を取得（学習時間がない場合はデフォルト値0.0)

39    BigDecimal totalLearningTime = exerciseRecordsService.getTotalLearningTime(userId, courseId);

40    if (totalLearningTime == null) {

41        totalLearningTime = BigDecimal.ZERO;

42    }

43 

44    responseForm.setTotalLearningTime(totalLearningTime);

45    log.debug("TopRest (getTotalLearningTime) 呼び出し終了");

46 

47    return responseForm;

48}

実装内容の振り返り

1. ユーティリティクラスの活用

以前作成した DateUtils クラスを活用し、週の開始日と終了日を簡単に取得できました。このおかげで、日付操作をシンプルに保ち、コードの重複を避けることができました。

2. BigDecimalの利用

学習時間の合計を計算するために BigDecimal を使用しました。BigDecimal は精度の高い数値計算が可能で、浮動小数点誤差を防ぐために最適です。学習時間がない場合は BigDecimal.ZERO を使用してデフォルト値を設定しました。

まとめ

今回の実装では、ユーティリティクラスの再利用と BigDecimal の活用で、精度高くシンプルなコードが書けました。これにより、学習時間計算が正確で信頼性のあるものとなり、保守性が向上しました。
次回も、各グラフの作成方法について記載しますのでお楽しみに！

The post 【はじめてのJava】ダッシュボードAPIを作成しよう！④総学習時間API編 first appeared on SMS DataTech.

こんにちは！マーケターから未経験のエンジニアに転身した社員Tです。

開発を始めて1年が経ち、サーバーサイド開発にも触れるようになりました。

今回は、Javaを使用したダッシュボードAPIの作成についてご紹介します。

これまでフロントエンド中心の開発を行っていた私が、サーバーサイドのAPI開発に挑戦していく様子をお届けします。

本記事の対象の方

• サーバーサイド開発をこれから学びたい方
• JavaでのAPI開発に興味がある方
• ダッシュボードの作成を通じて、実践的な技術を学びたい方

Javaとは？

Javaは、非常に人気のあるオブジェクト指向プログラミング言語で、さまざまなアプリケーションの開発に広く使用されています。

詳しい説明については、過去のブログ記事をご参照ください。
⇒過去のブログ一覧

環境構築

環境構築に関しては、内容が広範囲にわたるため、別の記事で詳細に解説する予定です。

ダッシュボードAPIの作成

今回作成したいのは、こんなダッシュボード画面です。ユーザーがコースを選択することで、自分の学習状況を一目で確認できるようにすることを目指しています。

全体の作成の流れとしては、下記の通りとなります。

1. ユーザー情報を取得
2. コース情報を取得
3. 各グラフ描画に必要なデータを取得

今回は、3.各グラフ描画に必要なデータを取得するAPIの実装について詳しく触れていきたいと思います。左上のログイン状況の表の制作に取り掛かりたいと思います。

1. ユーザー情報の取得については、過去のブログ記事をご参考ください。
⇒【はじめてのJava】ダッシュボードAPIを作成しよう！① ユーザー情報取得編

2. コース情報の取得については、過去のブログ記事をご参考ください。
⇒【はじめてのJava】ダッシュボードAPIを作成しよう！②コース情報取得編

ログイン情報取得APIの設計

取得したユーザーIDからログイン情報を取得し返却する。

エンドポイント

/top/getLoginHistoryByUserId

• HTTPメソッド: POST
• リクエストボディ: ユーザーID
• レスポンス: ログイン履歴のマップ

リクエスト例

{
  "userId":"175"
}

今回はパスパラメータではなく、リクエストボディからユーザーIDを受け取る設計にしています。これにより、柔軟なデータの受け渡しが可能となります。

レスポンス例

{
  "dailyLoginHistoryMap": {
    "monday": false,
    "tuesday": false,
    "wednesday": false,
    "thursday": false,
    "friday": false,
    "saturday": false,
    "sunday": false
  },
  "errorMessageList": null
}

ログイン情報取得APIの実装

ログイン情報を管理するモデルクラスの作成

まず、ログイン履歴を保持するエンティティクラスを作成します。

 1package jp.co.smsdatatech.questiongenerate.entity;
 2 
 3import java.io.Serializable;
 4import java.sql.Timestamp;
 5 
 6import lombok.Data;
 7 
 8/**
 9 * ログイン履歴テーブルEntity
10 */
11@Data
12public class LoginHistoryEntity implements Serializable {
13 
14    /** シリアルバージョンUID */
15    private static final long serialVersionUID = 1L;
16 
17    /** ユーザーID */
18    private Integer userId;
19 
20    /** 法人ID */
21    private Integer corporateId;
22 
23    /** ログイン日時 */
24    private Timestamp loginDate;
25}

MyBatisのMapper設定

次に、MyBatisのMapperを使用してデータベースからログイン履歴を取得します。getLoginHistoryByUserIdAndDateRange メソッドは、指定されたユーザーIDと日付範囲に基づいてログイン履歴を取得します。

 1<mapper namespace="jp.co.smsdatatech.questiongenerate.repository.LoginHistoryMapper">
 2 
 3    <select id="getLoginHistoryByUserIdAndDateRange" parameterType="map" resultType="java.time.LocalDateTime">
 4        SELECT DISTINCT
 5            login_date
 6        FROM
 7            login_history
 8        WHERE
 9            user_id = #{userId}
10            AND login_date BETWEEN #{startOfWeek} AND #{endOfWeek}
11        ORDER BY
12            login_date DESC
13    </select>
14</mapper>

サービスクラスの作成

サービスクラスで、ログイン履歴を取得するロジックを構築します。LoginHistoryService クラスでは、ユーザーIDを受け取り、ログイン履歴を取得します。

 1public class LoginHistoryService {
 2 
 3    /**
 4     * 指定されたユーザーIDに基づいてログイン履歴を取得する。
 5     *
 6     * @param userId ユーザーID
 7     * @return ログイン履歴（曜日ごとの情報）
 8     */
 9    @Transactional(readOnly = true)
10    public Map<String, Boolean> getLoginHistoryByUserIdAndDateRange(Integer userId) {
11        // 週の開始日と終了日を計算
12        LocalDateTime startOfWeek = DateUtils.getStartOfWeek();
13        LocalDateTime endOfWeek = DateUtils.getEndOfWeek();
14 
15        log.debug("ユーザーID {} のログイン履歴を週の範囲 {} - {} で取得します。", userId, startOfWeek, endOfWeek);
16 
17        // データベースからログイン履歴を取得
18        List<LocalDateTime> loginHistory = loginHistoryMapper.getLoginHistoryByUserIdAndDateRange(userId, startOfWeek, endOfWeek);
19 
20        Map<String, Boolean> dailyLoginHistoryMap = DateUtils.initializeWeekMap();
21 
22        DateTimeFormatter dayFormatter = DateTimeFormatter.ofPattern("EEEE", Locale.ENGLISH);
23        for (LocalDateTime login : loginHistory) {
24            if (login != null) {
25                String dayOfWeek = login.format(dayFormatter).toLowerCase(Locale.ROOT);
26                dailyLoginHistoryMap.put(dayOfWeek, true);
27            }
28        }
29        return dailyLoginHistoryMap;
30    }
31}

コントローラークラスの作成

コントローラークラスでは、APIのエンドポイントを定義し、サービス層を呼び出してレスポンスを返します。

 1public class TopRest {
 2 
 3    /**
 4     * ログイン状況取得.
 5     *
 6     * login_historyテーブルからユーザーIDに紐づくログイン状況を取得し、LoginHistoryResponseFormに詰めて返却する。
 7     *
 8     * <h3>処理フロー</h3>
 9     * 1. ログイン履歴を取得<br>
10     * 2. 取得データを返却
11     *
12     * <h3>レスポンス構成</h3>
13     * - **loginHistoryByDay**: 曜日ごとのログイン状況（キー: 曜日、値: true/false）<br>
14     * - **error**: エラー発生時のメッセージ
15     *
16     * @param form    Top画面UserId用Form
17     * @param result  バリデーション結果
18     * @return ログイン履歴情報 LoginHistoryResponseForm
19     */
20    @PostMapping("/top/getLoginHistoryByUserId")
21    public LoginHistoryResponseForm getLoginHistoryByUserId(@RequestBody @Valid UserIdForm form, BindingResult result) {
22        List<String> errorMessageList = new ArrayList<>();
23        LoginHistoryResponseForm responseForm = new LoginHistoryResponseForm();
24 
25        Set<String> processedFields = new HashSet<>();
26 
27        // バリデーションエラーがある場合、詳細なエラーメッセージを追加
28        if (result.hasErrors()) {
29            for (FieldError fieldError : result.getFieldErrors()) {
30                // フィールド名を基に重複チェック
31                if (!processedFields.contains(fieldError.getField())) {
32                    String errorMessage = messageSource.getMessage(fieldError, Locale.getDefault());
33                    errorMessageList.add(errorMessage);
34                    processedFields.add(fieldError.getField());
35                }
36            }
37            responseForm.setErrorMessageList(errorMessageList);
38            return responseForm;
39        }
40 
41        // ユーザーIDを整数に変換
42        Integer userId = Integer.parseInt(form.getUserId());
43 
44        // サービス層で曜日ごとのログイン履歴を取得
45        Map<String, Boolean> dailyLoginHistoryMap = loginHistoryService.getLoginHistoryByUserIdAndDateRange(userId);
46 
47        // ログイン履歴が空かどうかをチェック
48        if (dailyLoginHistoryMap.isEmpty()) {
49            errorMessageList.add(messageSource.getMessage(ErrorMessages.NO_LOGIN_HISTORY, null, Locale.getDefault()));
50            responseForm.setErrorMessageList(errorMessageList);
51            return responseForm;
52        }
53 
54        responseForm.setDailyLoginHistoryMap(dailyLoginHistoryMap);
55        return responseForm;
56    }
57}

日付および曜日に関するユーティリティクラス

ログイン履歴の処理に役立つユーティリティメソッド（例：曜日の初期化や日付の範囲計算など）を別途 DateUtils クラスとして用意します。

 1public class DateUtils {
 2 
 3    /** 曜日をまとめた配列 */
 4    protected static final String[] DAYS_OF_WEEK = {
 5            "monday", "tuesday", "wednesday", "thursday", "friday", "saturday", "sunday"
 6    };
 7 
 8    /**
 9     * プライベートコンストラクタでインスタンス化を禁止する
10     */
11    private DateUtils() {
12        throw new UnsupportedOperationException("このクラスはインスタンス化できません");
13    }
14 
15    /**
16     * 指定された日付の週の開始日（月曜日の00:00:00）を取得.
17     *
18     * @param date 基準日
19     * @return 週の開始日
20     */
21    public static LocalDateTime getStartOfWeek(LocalDate date) {
22        return date.with(TemporalAdjusters.previousOrSame(DayOfWeek.MONDAY)).atStartOfDay();
23    }
24 
25    /**
26     * 現在週の開始日（月曜日の00:00:00）を取得.
27     *
28     * @return 現在週の開始日
29     */
30    public static LocalDateTime getStartOfWeek() {
31        return getStartOfWeek(LocalDate.now());
32    }
33 
34    /**
35     * 指定された日付の週の終了日（日曜日の23:59:59）を取得.
36     *
37     * @param date 基準日
38     * @return 週の終了日
39     */
40    public static LocalDateTime getEndOfWeek(LocalDate date) {
41        return date.with(TemporalAdjusters.nextOrSame(DayOfWeek.SUNDAY)).atTime(LocalTime.MAX);
42    }
43 
44    /**
45     * 現在週の終了日（日曜日の23:59:59）を取得.
46     *
47     * @return 現在週の終了日
48     */
49    public static LocalDateTime getEndOfWeek() {
50        return getEndOfWeek(LocalDate.now());
51    }
52 
53    /**
54     * 曜日ごとの初期マップを作成（初期値はすべてfalse）.
55     *
56     * @return 曜日をキーにしたマップ（値はすべてfalse）
57     */
58    public static Map<String, Boolean> initializeWeekMap() {
59        Map<String, Boolean> weekMap = new LinkedHashMap<>();
60        for (String day : DAYS_OF_WEEK) {
61            weekMap.put(day, false);
62        }
63        return weekMap;
64    }
65}

実装内容の振り返り

今回の実装で、ログイン履歴を週ごとに取得する処理において、複数回使用される処理（例えば、曜日の初期化や日付の範囲計算）をユーティリティクラスにまとめることができました。この部分は非常に勉強になりました。

ユーティリティクラスを作成することで、以下のようなメリットを実感できました。

• 再利用性の向上：一度作成した共通部品を他の部分でも利用できるようになり、コードの重複を減らすことができました。これにより、将来的にメンテナンスがしやすくなります。
• 可読性の向上：ユーティリティメソッドを使うことで、メインのビジネスロジックがシンプルになり、読みやすくなりました。例えば、曜日の初期化処理や日付範囲の計算などがユーティリティクラスに隠蔽されているため、コントローラークラスがすっきりとしたものになりました。
• テストのしやすさ：共通の処理をユーティリティクラスにまとめることで、その部分を個別にテストすることができ、ロジックの正確性を担保しやすくなりました。

これらを踏まえて、ユーティリティクラスはシステム全体のコードをより効率的に、そして保守しやすくするための強力なツールだと改めて実感しました。

まとめ

効率的なコードを書くための方法を一つ引き出しを増やせたことが良かったです。特に、複数のクラスで使い回す共通の処理や汎用的で一貫性が求められる処理をユーティリティクラスにまとめることが、コードの効率化や保守性向上に大いに役立つと感じました。

次回も、各グラフの作成方法について記載しますのでお楽しみに！

筆者：K・T（20代）

所属：ハイブリット・マルチクラウド部

マーケターとしてWEB広告運用やアパレルブランドの運営に携わってきたが、エンジニアとしての新たな挑戦を決意した転職組。
好奇心が旺盛で、新しいことに挑戦する姿勢が彼女の魅力。
マーケター×エンジニアの強みを生かし、UI/UXの提案から実装まで幅広く対応し、彼女自身がブランドを育てているのだろうと思わせてくれる、そんな20代の乙女。

The post 【はじめてのJava】ダッシュボードAPIを作成しよう！③ログイン状況可視化編 first appeared on SMS DataTech.

• メルマガの企画を考える時間がない
• 件名や本文の作成に毎回時間がかかる
• 配信後の分析まで手が回らない
• 開封率やクリック率は見ているが、次回改善に活かせていない
• 読者リストの見直しや最適化が後回しになっている
• マーケティング施策を増やしたいが、人手が足りない

このような課題を解決する手段として注目したいのが、ClaudeCowork です。ClaudeCowork は、ChatGPT のような生成 AI の AI チャットのように回答を返すだけでなく、指定したファイルやフォルダをもとに、複数ステップの作業を進められるエージェント型 AI です。本記事では、ClaudeCowork を活用して、メルマガ作成・配信結果の分析・改善案作成・リスト最適化までを一貫して効率化する方法を解説します。

この記事がおすすめな方

この記事は、以下のような方におすすめです。

• メルマガを運用しているが、作成だけで手一杯になっている方
• メルマガの開封率やクリック率を改善したい方
• 配信後の分析やリスト最適化まで手が回っていない方
• ClaudeCowork をマーケティング業務に活用したい方
• AI を単発の文章作成ではなく、業務プロセスに組み込みたい方
• 人手不足の中で、より多くのマーケティング施策に取り組みたい方

なぜメルマガ業務に ClaudeCowork が向いているのか

通常の AI チャットでも、メルマガの件名案や本文案を作ることはできます。しかし、実際のメルマガ業務で必要なのは、文章を 1 本作ることだけではありません。メルマガ運用では、以下のような情報を見ながら判断する必要があります。

• 過去に配信したメルマガ原稿
• 開封率やクリック率などの配信結果
• 読者リストや顧客属性
• 商品・サービス情報
• セミナーや資料などの案内内容
• ブランド表現ルール
• 営業現場でよく聞かれる質問
• 過去に反応がよかったテーマ

通常の AI チャットでは、これらの情報を毎回貼り付けたり、ファイルをアップロードしたり、出力結果を別ファイルに保存したりする手間が残ります。一方、ClaudeCowork では、指定したフォルダ内の資料を読み込み、整理し、分析し、成果物を出力するまで一気通貫で進められます。メルマガ業務は、毎月・毎週のように繰り返し発生します。単発で文章を作るだけでなく、過去の結果を見て、次回の配信に活かす仕組みを作ることが重要です。そのため、メルマガ運用を一気通貫で自律して行える ClaudeCowork がメルマガ業務には向いています。

メルマガ業務でよくある課題

メルマガは、運用しているだけでは成果が伸びにくい施策です。本来は、配信ごとに結果を確認し、読者の反応を見ながら改善していく必要があります。しかし、多くの現場では、日々の業務に追われて改善まで手が回らないケースがあります。

メルマガ運用で起こりやすい課題

特に重要なのは、配信後の分析とリスト最適化です。メルマガは、作成して配信するだけでは終わりません。どの件名が開封されやすかったのか、どのテーマがクリックされやすかったのか、どの読者層が反応したのかを整理することで、次回以降の配信精度を高めることができます。

ClaudeCowork で効率化できるメルマガ業務

ClaudeCowork を活用すると、メルマガ業務のさまざまな工程を効率化できます。メルマガ本文の作成だけに使うのではなく、企画・分析・改善・リスト最適化まで含めて自動化することが可能です。

ClaudeCowork で効率化できる業務一覧

ClaudeCowork の価値は、作業時間の短縮だけではありません。これまで時間が足りずに後回しになっていた内容分析やリスト最適化まで、一連の運用フローに組み込めることが大きなポイントです。

実践！ClaudeCowork でメルマガ改善を進める 4 つのステップ

ここからは、ClaudeCowork を使ってメルマガ改善を進める方法を、4 つのステップに分けて紹介します。

ステップ 1：メルマガ改善の目的を決める

まず、ClaudeCowork に作業を依頼する前に、メルマガ改善の目的を決めます。ここで大切なのは、メルマガの目的を 1 つに固定しないことです。メルマガは、企業の状況や施策によってさまざまな目的で活用できます。例えば、ノウハウや新しい記事の情報提供による自社サイトへの流入やセミナーの申し込みなどがあります。目的が曖昧なまま ClaudeCowork に依頼すると、きれいな文章はできても、成果につながりにくくなります。そのため、まずは「今回のメルマガで何を改善したいのか」を明確にします。

たとえば、次のように整理します。

• 開封率を上げたい
• クリック率を改善したい
• 特定テーマへの関心を確認したい
• セミナー参加につなげたい
• 資料ダウンロードを増やしたい
• 長期間反応がない読者を掘り起こしたい
• 読者リストを関心別に整理したい

ClaudeCowork を使う前の設計が明確であるほど、出力される分析や改善案の精度も上がりやすくなります。

ステップ 2：必要なファイルを整理する

次に、ClaudeCowork に読み込ませる資料を整理します。メルマガ改善では、過去の配信原稿や配信結果だけでなく、商品情報、読者リスト、ブランド表現ルールなども重要です。

用意するファイル例

mailmagazine-improvement/
├── input/
│   ├── 過去メルマガ原稿.md
│   ├── 配信結果.csv
│   ├── 顧客リスト.csv
│   ├── 商品サービス概要.md
│   ├── セミナー情報.md
│   ├── 資料一覧.md
│   ├── ブランド表現ルール.md
│   └── 分析観点.md
└── output/

このように、input フォルダと output フォルダを分けると、ClaudeCowork に作業を依頼しやすくなります。input フォルダには、分析や作成に必要な元資料を入れます。output フォルダには、ClaudeCowork が作成する分析レポート、件名案、本文案、リスト改善案などを保存します。

分析観点.md に入れる内容例

# 分析観点
- 開封率が高かった件名の傾向
- 開封率が低かった件名の傾向
- クリック率が高かった本文構成
- クリック率が高かった CTA の傾向
- 反応がよかったテーマ
- 反応が低かったテーマ
- 読者属性ごとの反応差
- 長期間反応がない読者の傾向
- 次回メルマガで改善すべき点
- 配信リストの見直し候補

ここで重要なのは、ClaudeCowork に「何を見てほしいのか」を先に決めることです。AI に自由に考えさせるよりも、人間が分析観点を定義したほうが、実務で使いやすい成果物になりやすくなります。

ステップ 3：ClaudeCowork に作業を依頼する

資料を整理したら、ClaudeCowork に作業を依頼します。このとき、「メルマガを作ってください」とだけ伝えるのではなく、目的、入力資料、成果物、注意点を明確に指定します。

プロンプト例

input/フォルダ内の資料をすべて読み込み、
過去のメルマガ配信結果を分析してください。

目的は、メルマガ業務を効率化し、
次回以降の配信内容を改善することです。

以下の成果物を output/フォルダに作成してください。

1. 過去メルマガの反応分析レポート
2. 開封率が高かった件名の傾向
3. クリック率が高かった本文・CTA の傾向
4. 反応が高かったテーマの整理
5. 反応が低かったテーマの整理
6. 読者リストの改善案
7. 次回メルマガの企画案
8. 件名案 10 本
9. 本文下書き 3 パターン
10. 次回配信後に見るべき指標

情報が確認できない場合は、推測せず「不明」と書いてください。
作業に入る前に、まず実行プランを提示してください。

プロンプトで押さえるべきポイント

• 成果物を番号付きで指定する
• 目的を明確にする
• 分析と作成を分ける
• 「不明な情報は不明」と書かせる
• 作業前に実行プランを出させる
• output フォルダに成果物を保存させる

ClaudeCowork は、複数ステップの作業を進められる点が特徴です。そのため、単発の文章作成ではなく、「分析して、改善案を出し、次回の下書きを作る」という流れで依頼すると、実務に近い成果物を得やすくなります。

ステップ 4：成果物を確認し、次回配信に活かす

ClaudeCowork が出力した成果物は、そのまま使うのではなく、人間が確認して調整します。特に、メルマガは読者に直接届くため、事実確認や表現の調整が欠かせません。

成果物例 1：メルマガ反応分析表

このような表にすると、どの配信がよかったのかをチームで共有しやすくなります。また、AI 検索や生成 AI に引用される際にも、表形式の情報は要点を抽出しやすくなります。

成果物例 2：リスト最適化案

リスト最適化で大切なのは、全員に同じ内容を送り続けないことです。読者ごとの関心や反応に合わせて配信内容を変えることで、メルマガの成果を改善しやすくなります。

成果物例 3：次回メルマガ企画案

このように、ClaudeCowork を使うと、メルマガを「作るだけ」の業務から、「分析して改善する」業務へ変えやすくなります。

実際に使って分かったポイント

ClaudeCowork を活用して特に効果を感じやすいのは、メルマガ本文の作成よりも、むしろ配信後の分析や改善案の整理です。これまでのメルマガ運用では、配信後に開封率やクリック率を見るだけで終わってしまうことが多くありました。しかしClaudeCowork を活用することで、以下のような作業まで一貫して進めやすくなります。

• 過去メルマガの内容を読み取る
• 配信結果を整理する
• 反応がよかったテーマを抽出する
• 件名や CTA の傾向を比較する
• 読者リストごとの反応差を見る
• 次回配信の改善案を作る
• 改善案をもとに本文下書きを作る

メルマガは、ただ配信数を増やせば成果が出るものではありません。読者の反応を見ながら、内容、件名、CTA、配信対象を少しずつ改善していくことで成果につながります。ClaudeCowork を使うことで、その改善サイクルを日々の運用に組み込みやすくなります。

ClaudeCowork に任せきりにしないための注意点

ClaudeCowork は、メルマガ業務の効率化に役立ちます。ただし、すべてを任せきりにするのは危険です。特にメルマガは顧客や見込み顧客に直接届くため、誤った情報や不自然な表現があると、企業の信頼に影響します。サービス情報やセミナー日程などは必ずチェックを行いましょう。ClaudeCowork は、調査、整理、初稿作成、分析補助の初速を上げる存在です。最終的な判断や戦略決定は、人間が行う前提で使うことが重要です。また、Anthropic 公式ページでは、ClaudeCowork は指定したファイルを扱える一方で、機密情報を含むローカルファイルへのアクセスには注意が必要であることも示されています。

ClaudeCowork 活用はメルマガ以外にも広げられる

メルマガ改善で ClaudeCowork の活用に慣れてくると、ほかのマーケティング業務にも展開できます。たとえば、以下のような業務です。

• 競合調査
• ホワイトペーパー作成
• セミナー企画
• 営業資料作成
• 顧客リスト整理
• 商談メモの要約
• 月次レポート作成
• SNS 投稿案の作成
• FAQ や社内ナレッジの整理

ClaudeCowork は、文章作成だけのツールではありません。業務に必要な資料を読み込み、整理し、分析し、成果物にまとめることで、マーケティング担当者の実務を支援できます。

⇒ClaudeCoworkの教科書｜BtoBマーケターが競合調査で押さえるべき4つのステップ

まとめ：ClaudeCowork はメルマガを「作る業務」から「改善する業務」に変える

本記事では、ClaudeCowork を活用してメルマガ業務を効率化する方法を解説しました。メルマガは送って終わりではなく、読者の反応を分析し、内容や配信リストを改善し続けることで成果につながります。ClaudeCowork を活用すれば、メルマガ作成だけでなく、過去配信の分析、改善案の作成、リスト最適化まで一貫して進めやすくなります。そのため、メルマガ業務を「作る業務」から、「継続的に改善する業務」へ進化させやすくなります。ただし、継続的に活用するには、任せる業務範囲や確認ルールを整理し、再現性のある運用フローとして社内に組み込むことが重要です。SMS データテックには、ClaudeCowork を活用した業務全体の自動化と運用定着を支援する「Claude Cowork 内製化支援」サービスがあります。貴社の業務・体制に合わせた活用可能性と課題を無料相談で整理できます。お気軽にお問い合わせください。

The post ClaudeCoworkの教科書｜BtoBマーケターがメルマガ改善で押さえるべき4つのステップ first appeared on SMS DataTech.

最近はChatGPTやClaudeなどのAIチャットを活用する人も増えていますが、「ファイルを毎回アップロードする」「URLを1つずつ渡す」「出力をコピペでスプレッドシートに貼り付ける」といった作業は依然として残りがちです。単発のAI質問では、業務プロセスとしての効率化までは届きません。

そこで今回は、Claude Cowork（以下、Cowork）を使って、自社のあるBtoB SaaS（以下、製品A）の競合分析レポートをどこまで自動化できるかを検証しました。本記事では、その手順と実際に使って分かった勘所をまとめます。

この記事がおススメな方

• BtoB SaaS・サービスのマーケティング担当者
• 競合調査を定期的に行っている方
• AIを単発質問ではなく、業務プロセスとして組み込みたい方

なぜChat UIではなく「Cowork」で競合調査を行うのか

Claude Coworkとは

Claude Coworkは、Anthropicが提供するデスクトップ向けのAIエージェントツールです。チャットUIのように1問1答で答えるだけでなく、ローカルフォルダの読み書き、Web調査、ファイル生成といった一連の作業を、ひとまとまりのタスクとして任せられるのが大きな特徴です。エンジニアでなくても、部下に命令するように自然な言葉で依頼することができ、自分のPC上の資料とWeb情報を組み合わせて、業務単位でAIに作業を任せられます。

実践！製品Aと競合A〜Dを比較してみた

今回の検証は、自社のBtoB SaaS（製品A）を題材に、同カテゴリの競合サービス4社（競合A〜D）を比較する形で行いました。

• 自社サービス：製品A（BtoB SaaS、マーケ/営業関連領域）
• 比較対象　　：競合A～D（同カテゴリの主要プレイヤー）
• 目的　　　　：マーケティング観点での競合比較と打ち手検討
• 成果物　　　：機能比較表、料金比較表、ポジショニングマップ、示唆サマリー、施策案

競合調査は「プロンプト」より「事前設計」で決まる

Coworkで競合分析を任せる際、もっとも重要なのはプロンプトではなく事前準備です。

AIに自由に調べさせると、比較軸が散漫になり、最終アウトプットが「それっぽいが浅いサマリー」になりがちです。これを避けるには、人間が先に「何を、どの観点で比較するか」だけ決めておく必要があります。

用意したフォルダ構成

検証では、以下のシンプルな構成にしました。

competitive-analysis/
├── input/
│   ├── 製品A_サービス概要.md
│   ├── 製品A_価格表.xlsx
│   ├── 競合リスト.md         # 競合A〜DのURL・基本情報
│   ├── 分析観点.md
│   └── 過去の分析メモ.md
└── output/

「input/」に判断材料となる資料を入れ、「output/」 を成果物の保存先として指定するだけのシンプルな設計です。ポイントは、入力と出力のディレクトリを物理的に分けておくことです。これだけで「成果物がどこにあるか分からない」問題が消えます。

分析観点.md の中身が成否を分ける

特に重要なのが「分析観点.md」です。今回は以下のような項目を事前に書き出しました。

# 比較観点
- 主要機能
- 料金体系・提供条件
- 対象企業規模
- CRM / MA連携
- レポート機能
- 導入支援・カスタマーサクセス体制
- セキュリティ対応
- LPの主な訴求メッセージ
- CTA設計（資料請求 / 無料トライアル / デモ予約 など）

ここを丁寧に書いておくと、Coworkが返してくる比較表のクオリティが目に見えて変わります。「比較軸の設計は人間の仕事、調査と整理はCoworkの仕事」という分業が、自動化のコツです。

実行前に「一緒にプランを練る」のがCoworkの作法

ここがCowork特有の使い方なのですが、いきなり「分析を実行して」と命じる前に、先にプランを相談するのがおすすめです。

Coworkはタスクを受け取ると、実行する前にまずプラン（手順案）を提示してくれます。これに対して、

• 「比較観点XとYは順序を入れ替えてほしい」
• 「料金は公開価格と要問合せを別カラムにして」
• 「競合DはLPだけでなくプレスリリースも見て」

といった修正指示を実行前にぶつけられます。実行が始まってから差し戻すよりも、ここで擦り合わせた方が出力品質が安定します。

実務ではプロンプト送信後にこのプランが提示されるので、慌てず一度読み、納得してから「承認して進めて」と返すだけです。「使い方の型」として覚えておく価値があります。

Coworkに渡したプロンプト

事前準備ができたら、Coworkにゴールを伝えます。実際に渡したプロンプトは以下のとおりです（そのまま転用できる形にしています）。

input/ フォルダ内の資料をすべて読み込み、
競合リスト.md に記載された各社についてWeb調査を行い、
分析観点.md に沿って製品Aの競合分析レポートを作成してください。

成果物はすべて output/ フォルダに保存してください。

作成するもの：
1. 機能比較表
2. 料金・提供条件の比較表
3. ポジショニングマップ
4. 各社の強み・弱み
5. 製品Aの改善余地
6. 次に取るべきマーケティング施策案

情報が確認できない項目は、推測せず「不明」と明記してください。
作業に入る前に、まず実行プランを提示してください。

ポイントは2つです。

1. 成果物のリストを明示する：何を作ってほしいかを箇条書きで指定すると、出力構成のブレがなくなります
2. 「不明は不明と書く」ルールを入れる：これを書かないと、Coworkは公開情報がない箇所を”それっぽく”埋めてしまうことがあります

Coworkが実行した作業

プランの擦り合わせ後、Coworkは以下の流れを自律的に実行してくれました。

1. 「input/」フォルダの資料を読み込み、製品Aと比較観点を把握
2. 「競合リスト.md」を起点に競合A〜DのWeb調査を実施
3. 比較観点ごとに各社情報を収集・整理
4. 機能比較表・料金比較表をMarkdown／表形式で生成
5. ポジショニングマップ用の整理データを作成
6. 各社の強み・弱み、製品Aの改善余地、施策案をテキストでサマリー
7. 成果物をすべて「output/」フォルダに保存

人間がやると地味に時間のかかる「読む → 調べる → 並べる → 表にする → 保存する」を、ひとまとめに任せられるのが大きな価値です。途中で「ここは違う」と思ったらチャット側から介入もできるので、「ある程度任せつつ、要所で口を出す」運用が現実的です。

成果物の中身（一部抜粋）

具体的な比較結果は伏せますが、出力されたファイルの感触をつかんでもらうため、構造とサマリの一部だけ公開します。

機能比較表（フォーマットのみ）

製品Aと競合A〜Dを縦横で並べ、対応状況を記号で整理。「output/feature-matrix.md」と「.xlsx」の両方が生成されました。実際の中身はこんな見た目です（評価値はマスキング）。

凡例：◎強い / ○対応 / △限定的 / ✕非対応 / 不明

料金・提供条件の整理

公開料金があるサービスとないサービスが混在するため、「公開／要問い合わせ／不明」を明示する形で整理されていました。競合の中でも価格戦略の考え方には明確な違いが出ており、製品AのプライシングLPを見直す材料になりました。

ポジショニングマップ

「機能網羅性」×「導入のしやすさ」の2軸で配置されたところ、競合A・Cは機能網羅型として右上、競合B・Dは導入容易性に振った左下、製品Aは中央やや右下という分布になりました。

イメージとしては以下のような配置です。

なお、後述するとおり軸の妥当性は人間レビューが必須です。

示唆サマリー（Cowork出力をベースに筆者整理）

成果物には1〜2ページの示唆サマリーが含まれていました。具体的な内容は伏せますが、構造としては以下のようなトピック粒度で書かれていました。

• 競合A／Cは大企業向けの高機能化、競合B／Dは中小企業向けの低価格・短期導入を志向。市場が「機能厚め × 大企業」と「軽量 × SMB」の二極に寄っている様子が読み取れる
• 製品Aは中規模企業向けのバランス型ポジションを取り得るが、現行LPでは訴求軸が機能寄りに振れすぎており、「導入の運用しやすさ」が伝わっていない可能性がある
• 次の打ち手候補：①LPファーストビューの訴求軸見直し、②比較資料に「運用工数の差分」を追記、③ウェビナーでの導入事例コンテンツ強化

このレベルの初稿が出てくるので、チームでの議論のたたき台としてはかなり十分です。

実際に使って分かった注意点

ここからが本記事で一番伝えたい部分です。Coworkは万能ではありません。実務で使うなら、以下の点を理解しておくと事故が減ります。

1. 公開情報だけでは埋まらない項目がある

特に料金や詳細機能は、ログイン後にしか見られないSaaSも多く、「不明」が並ぶことは普通にあります。これは仕様であり、無理に埋めさせない方が品質は安定します。

2. ポジショニングマップの軸は人間が確認する

軸の取り方ひとつで結論が変わるのがポジショニングマップです。Coworkが提案した軸はあくまで叩き台として、最終的にはマーケ担当者が業界文脈で見直す前提で扱うべきです。今回も初稿の軸は1度差し戻し、業界の購買決定要因に近い軸へ調整しました。

3. 競合サイトの表現を鵜呑みにしない

公式サイトの訴求は当然ポジティブに書かれています。それをそのまま比較表に流すと、「全社が万能サービス」のような薄い比較になります。自社視点的な再評価を必ず一段階挟むのがおすすめです。

4. 戦略判断は人間の仕事

施策案は便利ですが、そのまま実行できるレベルではありません。製品Aの予算・リソース・優先度を踏まえた絞り込みは、最後まで人間の役割です。

Coworkは「調査と整理の初速を上げる存在」。戦略の意思決定そのものを置き換えるツールではない、と捉えると現場運用がしやすくなります。

次回からは”1行で済む”：Skillsで類似業務を量産する

ここまでの流れを1回限りで終わらせるか、毎月再現できる仕組みにできるかで、現場の効率は大きく変わります。

Coworkには Skills（スキル） という、再利用可能なワークフロー機能があります。今回の競合調査で得たノウハウ（フォルダ構成・観点の並び順・出力ファイルの命名規則など）をひとまとめにパッケージ化しておけば、次回からは「製品Aの競合調査をして」と言うだけで、同じクオリティの成果物が再現できるようになります。

つまりSkillsとは、「うまくいった調査プロセス」をテンプレ化して、類似業務を量産できるようにする仕組みです。一度作ってしまえば、競合調査だけでなくレポート作成・LP分析・営業資料更新など、フォーマットが似た業務にも横展開できます。

ただし、Skillsの作り方や、組織内での粒度・命名・運用ルールづくりは別の論点になってきます。「自部門で試したいが、まず何から作ればいいか分からない」「部門展開でつまずきそう」という方は、後述のClaudeCowork内製化支援もご検討ください。

まとめ：ClaudeCoworkは「便利なAI」ではなく「業務プロセス化できるAI」

最後に、本記事の要点を整理します。

• ClaudeCoworkは「PC上の資料の読み書き」「Web調査」「ファイル生成」を一気通貫で任せられるため、競合調査のような業務単位の作業に向いている
• 成功の鍵はプロンプトではなく事前設計。特に分析観点ファイルの精度が成否を分ける
• 実行前にプランを擦り合わせるステップを必ず挟む
• ClaudeCoworkは初稿作成と整理作業に強いが、比較軸の妥当性確認と戦略判断は人間の仕事
• Skillという便利な機能を使えば、類似業務の量産も可能
• Coworkは初稿作成と整理作業に強いが、比較軸の妥当性確認と戦略判断は人間の仕事

「AIで競合調査してみた」では終わらせず、自分の業務フローの中に組み込めるかを意識すると、Coworkの価値はぐっと立ち上がります。

マーケ担当者にとって、競合調査は今後ますます「人がやる作業」から「AIに任せて人がレビューする作業」へとシフトしていくはずです。本記事がその第一歩のヒントになれば幸いです。

ClaudeCoworkを自社の業務に組み込みたい方へ

弊社では、本記事のようなCowork活用の設計から、Skills整備・部門展開までを支援する 「Claude Cowork 内製化支援サービス」 を提供しています。「まず自部門で試したい」「すでに使い始めたが組織に広げる段階で詰まっている」など、フェーズに応じてご相談いただけます。無料診断で、貴社の業務・体制に合わせた活用可能性と課題を整理できますので、お気軽にお問い合わせください。

The post ClaudeCoworkの教科書｜BtoBマーケターが競合調査で押さえるべき4つのステップ first appeared on SMS DataTech.