目次

1. はじめに
2. Kiroについて
3. 実際に触ってみた
4. 感想
5. おまけ

1. はじめに

AIを使用してコーディングする場面を思い浮かべてください。
コード生成した結果、周辺とは違った書き方をされたり、余計な箇所を直されたり、意図しない修正をされて困った経験はありませんか？
他機能への影響が限定的な箇所や、とても簡単な機能の修正は、思い通りにいくことが多いですが、
他機能への影響が大きい改修など、機能の複雑度が高くなればなるほど上手くいかないことは顕著になりませんか？
本来はそんな(レバレッジの効きやすい)大規模な修正作業こそ、AIに任せたいものですよね。(しみじみ)

これらの問題の多くは、AIに「何を作りたいか」を正確に伝えられていないことが原因であることが多いと思います。
つまり、AIとの対話において、必要な情報を適切な形で提供できていないことが原因です。
プロンプトを調整したり、サービスとやり取りするチャットのセッションをリセットしたり、AIへの依頼方法を調整する行為をプロンプトエンジニアリングの上位概念として「コンテキストエンジニアリング」と言うらしいです。

調整したコンテキストをAIに依頼する。という熟練者達の暗黙知を
手段として提供しているAIコーディングエージェント「AWS Kiro」について、特徴や実際の操作についてまとめてみたので紹介します。

2. Kiroについて

AWS Kiroは、AIコーディングエージェントで、特にSpecモードが特徴的です。
公式ドキュメント

2.1. Spec駆動開発：AIとの対話を構造化する

従来のAIコーディングエージェントでは、「何を作りたいか」「どう作るか」はユーザの任意のタイミングで伝える必要がありました。
しかし、KiroのSpecモードは、開発プロセスを3つのフェーズに分けることで、AIとの対話を構造化してます。

• フェーズ1: 要件定義（Requirements）
  • 「何を作るか」を明確にする
  • ユーザーストーリーと受入基準を定義
  • この段階でレビュー・修正が可能
• フェーズ2: 設計（Design）
  • 「どう作るか」を設計する
  • アーキテクチャ、コンポーネント、テスト戦略を定義
  • 要件を基に自動生成され、レビュー・修正が可能
• フェーズ3: 実装計画（Tasks）
  • 「どの順番で作るか」を計画する
  • 具体的なタスクリストを生成
  • 設計を基に自動生成され、レビュー・修正が可能

この段階的なアプローチにより、各フェーズで必要な情報だけに集中することができ、AIに対して適切な情報を適切なタイミングで提供することができます。
結果として、AIが生成するコードの品質が安定し、意図しない実装を最小限にすることができます。

2.2. なぜSpec駆動開発が効果的なのか

Specモードの最大の特徴は、「AIに必要な情報を段階的に整理させる」という点です。

• 情報の整理
  • 各フェーズで必要な情報だけに焦点を当てられる
  • 前のフェーズの成果物が次のフェーズの入力になる
  • 情報の抜け漏れを防ぐ
• レビューポイントの明確化
  • 各フェーズで人間がレビュー・修正できる
  • 早い段階で方向性の誤りを修正できる
  • 実装前に要件と設計を確定できる
• 品質の安定化
  • 要件から実装までのトレーサビリティ
  • （ドキュメント次第ではありますが）プロパティベーステストを含む包括的なテスト戦略
  • 個々のエンジニアの経験に依存しにくい

つまり、Specモードは「AIとの対話の仕組み」そのものを改善することで、
（ある程度のレベルまでは）誰でも適切にAIに情報を伝えられるようになっています。

3.実際に触ってみた

今回はIDE版で進めていきます。
インストール・セットアップの手順については本記事では割愛します。
詳細は公式ドキュメントをご参照ください。

対象のプロジェクトに移動して「kiro .」でkiro.appが開きます
※kiro.appを開いて対象のプロジェクトを開くでも問題ないです。

「Spec」を選択して、早速以下のプロンプトを渡してみました

Kiroが requirements.md(要件ドキュメント) を作成してくれました
中身はこんな感じです

要件を確認して、修正したいところがあれば修正します。
今回はこのまま進めます。 Move to design phase を押下します。

要件に沿って Kiro が design.md(設計ドキュメント) を作成してくれました
アーキテクチャ、コンポーネント、データの永続化の方法論や、正常性プロパティ、テスト戦略まで、結構細かい粒度で設計をアウトプットしてくれました。

設計についてもこのまま進めます。 Move to implementation plan を押下します。

tasks.md(実装計画)が作成されました。
一部のタスクをオプション化してまずはコア機能のみの計画にするか or 最初から包括的に作成する計画にするか
聞かれたので、包括的に作ってもらいました。

Kiroにタスクの実行してもらいます。（チャットに「run all tasks」と入力） 実行中は以下のような感じで、進行状況がわかるようになってます。

最終的にできたアプリはこちらです。

• タスクの追加、削除、do/undoができる
• データの永続化ができてる（localstrageの範囲で）
• レスポンシブでシンプルなデザイン

4. 感想

「実際に触ってみた」のセクションで見てきたように、Specモードを使った開発では、
最初の簡単なプロンプトから

• 要件定義、設計、実装計画が段階的に生成
• 各フェーズで必要な情報が整理・確認することができ
• tasks.mdの実行中に何度かエラーが発生し（エラー解析＞修正を繰り返し）つつも、最終的に要件を満たすアプリを完成することができました

実際には、AIが提案する要件や、設計に対して、修正しながら進めていく事になると思います。
「要件定義、設計、実装計画」に時間をかける事で、品質や満足度の高いものを提供していければなと思いました。

AWS KiroのSpec駆動開発は、AIとの対話を構造化することで、品質を一定以上に得られる仕組みだと思います。
プロンプトの書き方ばかりに時間をかけるのではなく、最初から仕組み化されたツールを選ぶことも大切ですね。
ぜひ一度、試してみてはいかがでしょうか。

5. おまけ

AWS KiroにはCLI版の提供もあります。
以下の通り、インストール、pathの設定後に「kiro-cli」にて起動できます。 （メッセージは英語表示になってますが、日本語の質問すると日本語で返ってきました。）
エディターの縛りなく使用が可能です！！

最後に、「設計を明確にしてからAIに依頼することが大切」という観点でCursorのPlanモードについても記事を書いてます。
興味がありましたら、一緒に読んでいただけると嬉しいです。
CursorのPlanモードについての記事はこちら

最後の最後までお読みいただき、ありがとうございました。

1. はじめに
2. ポイント1:設計書を書いてもらいましょう
3. ポイント2:Geminiを使うときの指示の出し方
4. ポイント3:自分で修正したら「読み直して」と必ず伝える
5. まとめ

はじめに

生成AIを使ってコード生成や修正を行うことは、もはや特別なことではなくなってきました。 Gemini や CodeX、Copilot、Cursor など、選択肢も増え、「うまく使えばかなり楽になる」という実感を持っている方も多いと思います。

• 途中から意図と違う方向に進み始める
• さっきまでの前提を忘れたような修正をしてくる
• replace に失敗して延々とやり直しを始める

この記事では、生成AIでコードを書くときに安定して進めるためのちょっとしたポイントを紹介します。 特に、コード生成や修正を生成AIに任せる機会が多い方に向けた内容です。

ポイント1：設計書を書いてもらいましょう

機能追加、不具合修正やリファクタリングを生成AIに依頼するとき、いきなり「ここを直して」と指示していないでしょうか。 実はこのやり方だと、生成AIが目の前の修正作業だけに集中してしまい、全体の前提を忘れることがよくあります。 おすすめなのは、最初に「どういう修正をしたいのか」を設計書（Markdown）として書いてもらうことです。

初回の出力は、設計書を書かなくても比較的安定して良い結果が出ることが多いです。 しかし、修正や追加依頼を繰り返していくうちに、最初の前提を少しずつ忘れ、 意図と違う方向へ進み始めることがあります。

設計書を用意しておくことで、 「今回はこの前提で直していたよね」と立ち返ることができ、 迷走を防ぐだけでなく、迷走後のリカバリーにも役立ちます。

例えば、

• どんな不具合を直したいのか
• どの方針で修正したいのか
• 影響範囲はどこか

といった内容をまとめたドキュメントを作り、その上で 「調査結果や修正方針をこの設計書に追記してください」 と指示します。

こうしておくと、修正や追加依頼を重ねたときに、 最初の前提が少しずつ崩れていくことを防ぎやすくなります。 生成AIが迷走し始めたときも、設計書という"基準点"に戻すことができます。 また、途中でセッションを切った後でも、「この設計書通りに進めたけど、ここに不具合があるんだよね」 と前提を思い出させることができます。 前の情報のうち「大事なことだけ」を引き継ぐ手段として、設計書はとても有効です。

ただし、生成AIも人間と同じで、情報を大量に与えられると注意が分散する傾向があります。

そのため、毎回すべての設計書を読ませるのではなく、 今回の修正と関連する方針だけを再掲するほうが、 生成AIの注意が分散せず、出力が安定しやすいです。

ポイント2：Gemini を使うときの指示の出し方

これは Gemini を使っている場合の話ですが、git の履歴や差分を調査させるときに、 そのまま git log や git diff を実行させると、なぜか数分待たされることがあります。

そこでおすすめなのが、 「調査結果を一度ファイルに保存して、そのファイルを見て判断してください」 と指示することです。

例えば、git log や git diff の結果を一時ファイルに出力させてから、それを読み取らせるようにすると、驚くほどスムーズに進むことがあります。 理由は正直よく分かりませんが、少なくとも体感としては そのままコマンドを実行させるより安定します。

Gemini 特有の挙動かもしれませんが、一度試してみる価値があります。

ポイント3：自分で修正したら「読み直して」と必ず伝える

これもGeminiを使う場合に多い話なのですが、LLM全般に少なからずあるポイントと思われます。 生成AIに修正を任せている途中で、自分でソースコードやMarkdownを少し直したくなることはよくあります。

• 改行を整えたい
• 「てにをは」を直したい
• 変数名を変えたい
• 行の順番を入れ替えたい

こうした修正を 自分で行った後に、そのまま続きを依頼すると、生成AIが大混乱することがあります。replace コマンドが失敗し、「もう一回やります」を繰り返し、気づいたら10分過ぎてしまった⋯ということもよくあります。

これを防ぐためには、

「こちらで修正したので、最新の内容を読み直してください」

と、明示的に伝えることで改善されることがよくあります。 それでもうまくいかない場合は、無理に続けず セッションを切って新しく始める方が早いこともあります。

おそらく、モデル内部に前回の状態を強く保持していて、差分がうまく当たらず混乱しているのだろう、というのが推測です。 理由を説明すると気をつけてくれることもありますが、体感では半分くらいは無視されてしまいます。 そういうときは、割り切って新しいセッションで続きの作業を進めることがおすすめです。

また、せっかく「てにをは」やトンマナを修正したのに、 追加のドキュメント修正を依頼したら元に戻されることや、 こちらで変数名を変えたのに別の箇所の再修正を依頼したら、変数名まで元に戻された⋯ こうした現象もよく起こります。

その場合は、無理に続けるよりも、 一度セッションを切り替えるほうが結果的に早いことも多いです。

そしてそのときに役立つのが、ポイント1で紹介した設計書です。 設計書があれば、前提を明示的に再共有できるため、 新しいセッションでも迷走しにくくなります。

まとめ

CopilotやCursorでは、ここまで気を遣わなくてもよい、という話もあるようですが、 今回紹介したやり方でかなり安定して生成AIを使えるようになりました。 また、今回コード生成にフォーカスしていますが、コード生成以外の場合でも今回の3つのポイントは有効だと考えています。

生成AIは賢いですが、前提をどう渡すか、どう指示を出すか、どこで区切るかによって、結果は大きく変わります。 もし最近「生成AIが言うことを聞いてくれないな......」と感じている方がいれば、ぜひ一度お試しください。

目次

1. はじめに
2. プロジェクトの概要 ― 障害対応を生成AIで効率化する
3. 全体の構想 - PowerAutomate × Copilot Studioによる自動化
4. 実際に構築したフロー - Microsoft 365 Copilotでできること
5. 振り返りと教訓
6. おわりに

1. はじめに

2026年現在、生成AIサービスは目的や専門性に合わせて非常に多くの選択肢がありますが、その中でも、Microsoft Copilotは比較的、大企業に選ばれている印象があります。

本記事では、筆者が生成AIを活用したPoCの開発支援に携わった経験をもとに、Microsoft Copilotを利用した業務改善の一例を紹介します。当該プロジェクトにおいては、技術全般のサポートという役割で参画しました。全体の開発方針を考えたり、メンバーが開発で詰まりそうな箇所を先回りして技術調査したりといった裏方の立場です。直接開発を行ったのは先方のメンバーであり、非エンジニアのチームが主体となってPoCを推進したプロジェクトでした。

このプロジェクトでは、まずCopilot単体で実現できる機能を追求し、十分に実用的な仕組みを構築することができました。本記事の内容が、少しでもご参考になれば幸いです。

2. プロジェクトの概要 ― 障害対応を生成AIで効率化する

今回のPoCで対象としたのは、システム障害発生時の初動対応です。

多くの企業では、システムに障害が発生すると監視ツールなどから障害通知メールが届きます。担当者はそのメールの内容を確認し、障害の概要を把握したうえで、過去の事例やドキュメントを参照しながら発生原因を推測し、対応策を検討します。この一連の作業は、経験豊富な担当者であればスムーズに進められますが、経験の浅いメンバーにとっては時間がかかり、対応の遅れにつながることもあります。

そこで本PoCでは、障害通知メールの内容を生成AIに読み込ませ、以下の情報を自動的に生成させることを目指しました。

• 障害の概要(何が起きているかの要約)
• 想定される発生原因
• 推奨される対応策

これにより、経験の浅い担当者でも迅速に初動対応の方針を立てられるようになり、チーム全体の障害対応スピードの向上が期待できます。

3. 全体の構想 - PowerAutomate × Copilot Studioによる自動化

当初描いていた理想のフローは、障害通知メールの受信から対応策の共有までを、人手を介さずワンストップで完結させるものでした。具体的には、以下のような構成を想定していました。

【当初構想のフロー】

障害通知メール受信
↓
PowerAutomate(トリガー：メール受信)
↓ メール本文・件名などを抽出
Copilot Studio(生成AI処理)
↓ 障害概要・原因・対応策を生成
Teams(結果を通知)

まず、障害通知メールの受信をPowerAutomateのトリガーとして設定します。PowerAutomateがメールの本文や件名といった情報を抽出し、Copilot Studioへ連携します。Copilot Studioでは、あらかじめ設定したエージェント設定に基づいて、障害の概要や発生原因、対応策などを生成します。最後に、その生成結果をTeamsのチャネルへ自動投稿し、関係者全員がすぐに確認できる状態にします。

この構成が実現できれば、障害通知メールを受信してから対応策がチームに共有されるまでの流れがすべて自動化され、担当者は生成された対応策を確認して実際の対応に集中するだけで済みます。PowerAutomateとCopilot Studioの組み合わせは、Microsoft 365のエコシステム内で完結するため、追加のインフラ構築も不要であり、非エンジニアにとっても取り組みやすいアプローチとなっています。

4. 実際に構築したフロー - Microsoft 365 Copilotでできること

まずはCopilot Chatを使用して目的の情報取得を実現するために、以下のようなフローを構築しました。メールの取り込みは手動で行いますが、生成AIによる障害分析という核心部分はしっかりと実現できています。

【実際のフロー】

障害通知メール受信
↓ (手動)担当者がメール内容をコピー
Copilot Chat(生成AI処理)
↓ 障害概要・原因・対応策を生成
担当者が結果をもとに対応を実施

ステップ1：SharePointへのドキュメント格納とナレッジ登録

まず、事前準備として、障害対応に必要な資料やドキュメントをSharePointに格納します。たとえば、過去の障害対応履歴やサーバー管理台帳などが該当します。

次に、Copilot Chatのナレッジ設定で、これらのSharePoint上のドキュメントを参照先として登録します。これにより、Copilotは汎用的な知識だけでなく、自社固有の情報も踏まえた回答を生成できるようになります。

ステップ2：障害通知メールの内容をCopilot Chatへ入力

障害通知メールを受信したら、担当者はメールの本文をコピーし、Copilot Chatに貼り付けます。あらかじめ設定したエージェント設定をもとに、回答が生成されます。

ステップ3：生成結果をもとに対応を実施

従来であれば過去の資料を一つ一つ探し、経験と勘に頼って対応策を考えていたプロセスが、Copilot Chatへの入力ひとつで大幅に効率化されたことは、大きな前進です。

5. 振り返りと教訓

プロジェクト全体を振り返り、特に重要だと感じた教訓を共有します。

情報システム部門の協力は必須

ライセンスの管理や社内のITポリシーに関する判断は、情報システム部門の管轄であることが一般的です。 今回、業務部門のメンバー中心のプロジェクトで、先方の情報システム部門の担当者がプロジェクトに参加していなかったため、ライセンスやアクセス制約の確認が遅くなりました。

今後、同様の開発支援型プロジェクトに携わる際には、プロジェクトの初期段階で先方の情報システム部門の担当者をメンバーに加えていただくことを強く推奨するつもりです。

「完璧」でなくても価値は出せる生成AIサービスの強み

今回のPoCでは、一部分の実現のみとなってしまいました。しかし、手動のステップが入ったとしても、生成AIを活用した障害分析そのものは十分に機能し、従来の対応プロセスと比較して明確な効率化が達成できました。試験的に本PoCを実運用で取り入れたところ、一次切り分けにかかる時間は約80%削減し、目に見えるほど対応品質の安定性も向上したようです。

本件の事例がすべてのプロジェクトで当てはまるというわけではないですが、単体でも十分に既存業務の効率化を果たし得る生成AIサービスに対して改めてポテンシャルの高さを感じました。いまひとつ生成AIサービスの利用に二の足を踏んでいる企業様においても、カジュアルに試すことができるのは大きな魅力の一つだと思います。

6. おわりに

本記事では、Microsoft 365のCopilot Chatを活用した障害対応効率化のPoCについて紹介しました。

当初の理想であった完全自動化こそ実現できませんでしたが、一部分の実現であっても、生成AIを活用した業務改善は十分に可能であることを実感しました。SharePointにドキュメントを格納し、Copilot Chatのナレッジとして登録するだけで、自社の業務に特化した生成AIを構築することができます。この手順自体は、エンジニアでなくても十分に実行可能です。

まずは身近な業務課題をひとつ選び、Copilotに相談してみるところから始めてみてはいかがでしょうか。

目次

• 1. はじめに
• 2. Cursorの概要
• 3. 言語モデルの選択
• 4. 4つのモード
• 　4-1. Agentモード
• 　4-2. Askモード
• 　4-3. Planモード
• 　4-4. Debugモード
• 5. Rulesの設定
• 　5-1. プロジェクトルール
• 　5-2. ユーザールール
• 6. コードレビューでの活用
• 　6-1. レビュー用のプロジェクトルールを作成する
• 　6-2. レビュー対象の差分ファイルを作成する
• 　6-3. レビューしてもらう
• 7. おわりに

1. はじめに

生成AIを活用したコードエディタが急速に広まりつつある昨今、Cursorはその代表的な存在のひとつです。

私自身、とあるプロジェクトでCursorを使うことになったものの、使い始めて数日は正直なんとなくで使っていたところがありました。

そこで本記事では、

　・これからCursorを使ってみようとしている方
　・とりあえず使い始めたものの、手探りで使っている方

に向けて、実際の画面や設定例を交えながら、使ってみて「もっと早く知っておけばよかった」と感じたポイントをまとめてみました。

2. Cursorの概要

Cursorは、VSCodeをベースに生成AIを統合したコードエディタです。
既にVSCodeを使っている方であればCursorへの機能的・心理的な移行はスムーズかと思います。

コード補完や生成だけでなく、既存のプロジェクト全体を前提にした質問応答や、設計・実装の補助までをエディタ上で完結できる点が特徴です。

ChatGPTを別タブで使うのとは異なり、現在のコードやファイル構成を文脈として扱えるため、より実践的なやり取りが可能になります。

3. 言語モデルの選択

CursorではGPT系やGemini系など含めて様々な言語モデルを選択できますが、モデルごとに料金や得意な作業が異なります。

下の表では、2025年12月時点での代表的なモデルとその特徴について、入力単価が安い順に整理しています。
特徴についてはCursorに聞いてまとめてもらいました。

現状、公式ドキュメントにモデルごとの具体的な利用シーンが詳しく載っているわけではなく、実際には試しながら把握していく部分も多い印象です。

また、実際の開発では「これは軽い作業だからこのモデル」「次は設計だからこのモデル」とモデルを毎回切り替えるのは、思った以上に判断コストがかかります。

そのため、モデル選択にこだわりがない場合は、少なくとも最初はデフォルトのAutoを使うのが無難だと感じました。

Autoは、Cursorがタスク内容に応じて適切なモデルを自動で選択してくれるため、モデルの違いを意識せずに作業を進めることができます。

ただし、稀に「急に変なこと言い出したな」と感じる場面もあるため、その場合は明示的にモデルを選択する必要があるかと思います。

4. 4つのモード（Agent/Ask/Plan/Debug）

Cursorには、作業内容ごとに使い分けられるAgent / Ask / Plan / Debugの4つのモードが用意されています。
デフォルトではAgentモードで動作します。

言語モデルはデフォルトのAutoのままでも大きな問題は起きにくい一方で、モードについてはそれぞれの特徴を理解した上で使い分ける必要があると思っています。

4-1. Agentモード

Agentモードは、エディタ上でのコード作成やコマンド実行などの作業をCursorに任せたいときに使います。

新機能の実装やRspecのテスト作成など、実際に手を動かす開発作業をまとめて進められます。

一方で、Agentモードは「最終的にコードを直す」前提で動く傾向があります。

例えば「このエラーの原因は？」と単に質問しただけのつもりでも、原因が確定していない段階でもコードの修正まで進めてしまうことがあります。

そのため、考えを整理したいだけの場面や、まずは状況を理解したい段階では、後述する別のモードを選んだほうが快適でしょう。

4-2. Askモード

Askモードはその名の通り、質問や相談をしたいときに使います。

途中から入ったプロジェクトの既存コードの流れを理解したい場合や、この処理が何を意図して書かれているのかを確認したい場面などで有効です。

私の場合は費用を抑えるため、一般的な構文や言語仕様のようにプロジェクトの文脈が不要な内容はChatGPTで確認し、 文脈を踏まえた回答が必要な場合はAskモードを使うようにしています。

4-3. Planモード

Planモードは、実装に入る前に方針を整理・具体化したいときに使います。

こちらから要件や目的を伝えると、Cursorから前提条件や確認事項が提示されます。

それらのやり取りを踏まえて、実装方針や作業手順をMarkdown形式のドキュメントとしてまとめてくれます。

「何を作るか」「どこを直すか」などを文章として可視化できるため、少し規模のある改修や新機能を考える場面で役立ちます。

また、作成された計画ファイルは、後述するコードレビューでも活用できます。

※Planモードについてはコチラの記事でも詳しく紹介されているので是非ご覧ください。
Cursor Planモードのススメ：なぜ"いきなり書かせる"と事故るのか

4-4. Debugモード

Debugモードは、バグの原因特定から修正・検証までを進めたいときに使います。

バグの状況を伝えると、複数の仮説を立てたうえでログ出力の追加などのコード修正を行い、バグ再現のための画面操作やコマンド実行の手順を示してくれます。

その実行結果をもとに原因を絞り込み、修正案の提示や再修正を進めていく流れになります。

このモードは2025年12月にリリースされた比較的新しいもので、まだあまり試せてはいませんが、デバッグの進め方そのものを支援してくれる点が特徴的だと感じています。

5. Rulesの設定

Cursorには、振る舞いをあらかじめ調整できる「Rules」という仕組みがあり、プロジェクト固有の前提や自分の作業スタイルを共有した状態でCursorとやり取りできます。

Rulesには主にプロジェクトルールとユーザールールの2つがあり、いずれもCursor SettingsのRules and Commandsから設定できます。

5-1. プロジェクトルール

プロジェクトルールは、特定のプロジェクトごとに適用されるルールで、開発環境や作業前提などをCursorに伝えることができます。

例えば、RSpecをDocker Compose経由で実行する場合は以下のようなルールを設定できます。

--- alwaysApply: true --- RSpecのテストを実行する際は、必ず以下の形式で実行すること： - 'docker-compose exec web bundle exec rspec [テストファイルパス]' - 直接 'bundle exec rspec' を実行しないこと 例： - 全テスト: 'docker-compose exec web bundle exec rspec' - 特定ファイル: 'docker-compose exec web bundle exec rspec spec/models/user_spec.rb' - 特定行: 'docker-compose exec web bundle exec rspec spec/models/user_spec.rb:10'

このルールにより、CursorはRSpecを正しいコマンドで実行できるようになります。

ルールがない場合はデフォルトでbundle exec rspecなどを実行して失敗するため、毎回正しいコマンドを指示する必要があります。
（これが結構ストレスでした。。）

なお、alwaysApplyはルールの適用方法（Rules Type）の一つで、すべてのチャットセッションに自動的に適用されることを表しています。
適用方法は「そのルールをどのタイミングで適用するか」を指定するもので、全部で4つあります。

5-2. ユーザールール

ユーザールールは、すべてのプロジェクトに適用されるルールで、会話スタイルや個人の開発スタイルをCursorに伝えることができます。

例えば、私の環境では以下のようなルールがあらかじめ設定されていました。
（Cursorを日本語対応させた際に自動で追加されたのかもしれません。）

Always respond in Japanese

このように、ユーザールールはプロジェクトルールとは異なり1~2文程度で簡潔に記載するのが良いようです。

6. コードレビューでの活用

Cursorは実装や修正だけでなく、コードレビュー用途でもかなり使えます。

今のところ、以下のような手順でレビューしてもらっています。

6-1. レビュー用のプロジェクトルールを作成する

例えばこのようなルールを作成します。

--- alwaysApply: true --- # コードレビュールール コードレビューを行う際は、このファイルを必ず参照し、 最初に「review.mdcファイルを参照しました」と出力すること。 ## チェック項目 ### 1. コーディング規約・品質 - [ ] RuboCop（.rubocop.yml）に準拠しているか - [ ] 可読性が保たれているか（命名・責務・重複コード） - [ ] デバッグコードや不要なコメントが残っていないか ### 2. テスト - [ ] 変更内容に対応するテストが書かれているか - [ ] エッジケース・異常系が考慮されているか ### 3. セキュリティ・安全性 - [ ] SQLインジェクション / XSS / 認可まわりに問題がないか - [ ] 機密情報がハードコードされていないか ### 4. パフォーマンス - [ ] N+1など明らかな非効率がないか - [ ] 大量データを扱う処理が妥当か ### 5. 仕様・ロジック - [ ] 計画ファイル・仕様に沿った実装になっているか - [ ] ロジックの誤りや境界値の考慮漏れがないか - [ ] 既存機能への影響がないか ## レビュー時の参照物 - 差分ファイル（changes.diff 等） - Planモードで作成した計画ファイル ## レビューコメント - 各項目を '[x] / [ ]' で明示する - 必須修正と任意修正を区別する - 可能であれば改善案を添える

ちなみに、このルールはCursorと一緒に作ったもので、読みやすさを優先して短く整理しています。

実際にはプロジェクトごとに必要な観点を追加・調整する必要があると思います。

6-2. レビュー対象の差分ファイルを作成する

下記のようなコマンドを実行し、差分ファイルを作成します。

git diff origin/develop..HEAD > changes.diff

基底ブランチがmainの場合は、Cursorが用意している「Branch (Diff with Main)」シンボルを渡せば十分です。

一方、main以外を基底にしたい場合は、現状このようにgit diffで差分ファイルを作るのが一番確実そうです。

6-3. レビューしてもらう

Askモードを選択し、下記2つのファイルを渡して「レビューして」と入力します。

• 上記で作成したchanges.diff
• 実装前にPlanモードで作成した計画ファイル

Askモードを使うことで、コードを書き換えられずレビューに集中してもらえます。



7. おわりに

本記事では、実際にCursorを使ってみる中で、「もっと早く知っておけばよかった」と感じたポイントを中心に紹介してきました。

Cursorをこれから使い始める方や、すでに使ってはいるものの活用しきれていないと感じている方にとって、少しでも参考になれば幸いです。

想定読者

• Cursorを使い始めたけれど「なんとなくAskしか使っていない」方
• Copilotの延長のような感覚でAgentを使ってうまくいかなかった経験がある方
• 設計やレビューの工夫に関心がある方

目次

1. はじめに
2. Cursorの4つのモードと使い分け
3. Planモードでできること
4. Planモードの実践的な使い方
5. よくある失敗パターン
6. まとめ

1. はじめに

Cursorでコーディングしているとき、こんなことに心当たりはありませんか？

• とりあえず個別に分からないことをAskモードで都度質問しているけど、なんとなく思ったような答えが得られなくて堂々巡りになってしまう
• 全体の方針や設計を固めずに、いきなりAgentモードで「こんな機能作って」と任せてみたら、意図していないコードやイマイチな実装が返ってきてしまったことがある
• 要件や意図がLLM（AI）にちゃんと伝わっていないまま進めてしまい、「なんでこうなった？」と感じた経験がある

実はCursorは4つの試行モードを持っています。それがAsk / Agent / Plan / Debugです。
なぜコードの質が安定しないのか？
その答えは、「設計を明確にせずに実装に進んでしまう」ことにあると自分は考えています。
Agentモードは優秀ですが、前提が曖昧だと迷走し、その場しのぎのコードを量産しやすい傾向がある。とも。。

それぞれのモードの特徴を理解することで、コードの質を安定させ、設計を明確にしながら効率的に開発しやすくなると信じています。
Cursorを使用してみて、また調べたりした中での自分なりの解釈も含まれていると思いますので、一解釈として捉えていただければ幸いです。
その結果「自分はこう思う」、「この箇所はこうだ」という議論のきっかけにつながれば嬉しいなという思いです。
最後までお付き合いいただけると大変嬉しいです。

2. Cursorの4つのモードと使い分け

それぞれのモードについて順番に確認していきましょう。
公式ドキュメントはこちらです：https://cursor.com/ja/docs/agent/modes

2.1. Ask モード：壁打ち・検索・局所理解

• 役割
  • 質問・調査・コードリーディング補助
  • ChatGPT的だが「今開いているコード」を文脈に持てる
• 向いている用途
  • 「このメソッド何してる？」
  • 「Railsでこれどう書く？」
  • 「このエラーが出た時の対処方法は？」
• 弱点
  • 複数ファイルをまたぐ判断が不安定になりやすい

2.2. Agent モード：実装を"手で書かせる"

• 役割
  • コード生成・修正・リファクタ
  • 指示に基づきファイルを編集する実行役
• 向いている用途
  • 単機能の追加
  • 定型リファクタ
  • テスト生成
• 危険ポイント
  • 設計を渡さずに使うと事故りやすい
  • その場しのぎのコードを"それっぽく"量産する傾向がある

2.3. Debug モード：バグの再現と修正支援（2025年12月追加）

• 役割
  • ランタイムログを埋め込んでバグの再現と修正を支援
  • 複雑なバグの根本原因を特定
  • さまざまなスタック、言語、モデルで動作
• 向いている用途
  • 再現が困難なバグの調査
  • ランタイム時の動作確認
  • 複雑なバグの根本原因分析
• 特徴
  • 2025年12月10日のバージョン2.2で追加された比較的新しい機能
  • 実行時のログを自動的に収集・分析
  • バグの再現条件を特定しやすくする

2.4. Plan モード：設計・思考の言語化

Plan モードは「コードを書かないモード」です。それではなぜコードを書かないのか？

• 役割
  • 設計の整理・最適化
  • 実装前の計画立案
  • コード生成の指示を構造化
• Planモードの本質
  • コードを書かない
  • ファイルも編集しない
  • 「何を・なぜ・どう進めるか」を構造化することで、コードの質を向上させやすくなる
• なぜ Planモード が存在するのか？（自分なりの解釈です🙏）
  • LLMは「最初の前提」が曖昧だと破綻しやすい傾向がある
  • Agentにいきなり投げると問題が起きやすい：
    • 境界が曖昧（どこまで実装すべきか判断できない）
    • 責務が混ざる（単一責任の原則が守られない）
    • 後から直しづらい（設計意図がコードに反映されない）

2.5. 4つのモードの使い分け判断基準

では、実際にどのモードを使うべきか？作業の種類でざっくりと分類すると以下の通りだと考えています。

更に具体的な判断基準は以下の通りです。

• Askモード：コードを理解したい、調べ物をしたい時
  • 「このコードの意味は？」
  • 「このエラーの原因は？」
  • 「この機能の実装方法は？」
• Agentモード：設計が明確で、単一のタスクを実装したい時
  • 単機能の追加
  • 定型リファクタ
  • テスト生成
• Planモード：複雑なタスクや、設計を明確にしたい時
  • 複数ファイルにまたがる機能追加
  • 大規模なリファクタリング
  • 新規機能の設計検討
  • バグ修正の原因特定と修正計画
• Debugモード：バグの再現や調査が必要な時
  • 再現が困難なバグの調査
  • ランタイム時の動作確認
  • 複雑なバグの根本原因分析

3. Planモードでできること

2章で説明した通り、Planモードは「前提を固定するための安全装置」です。
なぜ本記事でPlanモードを特に強調するのかというと、「設計や前提を明文化するプロセス」こそが、実はコードの質と開発効率を大きく左右すると考えているからです。

ここからは、Planモードで実際にどんなことができるか、具体的な使い方や機能を見ていきましょう。

3.1.できること

Planモードでは、以下のようなことができます：

• 設計の整理・最適化
  • 実装前に設計を構造化して整理
  • 責務の分離や境界の明確化
  • 実装順序の最適化
• コード生成の指示を整理・最適化
  • Agentモードに渡す指示を明確化
  • 実装の粒度や範囲を定義
  • エラーハンドリングやテストの方針を決定
• リスクの事前発見
  • 実装前に設計上の問題点を発見
  • 依存関係や影響範囲の確認
  • 実装の難易度や工数の見積もり

3.2.弱点・注意点

Planモードにも以下のような限界があります：

• 設計責任はすべて人間にある
  • Planモードは設計を「整理」するだけで、設計自体は人間が考える必要がある
  • 良い計画を立てるためには、そもそも良い設計をインプットとして与える必要がある
• 計画の過信に注意
  • 計画はあくまで「仮説」なので、実装中に問題があれば柔軟に修正する必要がある
  • 計画が細かすぎると、実装の柔軟性を失う可能性がある
• 計画作成にも時間がかかる
  • 複雑なタスクほど計画作成に時間がかかる
  • 単純なタスクではAgentモードを直接使う方が効率的な場合もある

4. Planモードの実践的な使い方

Planモードの真価は、Agentモードと組み合わせることで発揮されます。
ここでは、最も効果的な使い方である「Plan → Agentの黄金パターン」と、実践的な使い方について紹介します。（黄金パターンは大げさかもです。。笑）

4.1. 基本フロー

1. Planモードで計画を作成
   • タスクの全体像を把握
   • 実装すべき機能を分解
   • 実装順序を決定
2. 計画をレビュー・修正
   • 計画の妥当性を確認
   • 不足している点を補完
   • 実装の優先順位を調整
3. Agentモードで実装
   • 計画に基づいて明確な指示を出す
   • 段階的に実装を進める
   • 各ステップで動作確認
4. 必要に応じて計画を見直し
   • 実装中に問題が発見されたら計画を修正
   • 柔軟に対応する

4.2. 実例：ユーザー認証機能の追加

• 悪い例（PlanなしでAgentに投げる）
  • プロンプト

    $ ユーザー認証機能を追加して

  • 結果
    認証ロジック、セッション管理、エラーハンドリングが混在し、後から修正が困難になる傾向がある。

• 良い例（Plan → Agentの黄金パターン）
  • Step 1：Planモードで計画を作成
    • プロンプト：

      $ ユーザー認証機能を追加したい。以下の要件を満たす設計を考えて：
      - メールアドレスとパスワードでのログイン
      - セッション管理
      - エラーハンドリング
      - テストコード

    • Planモードが生成する計画例
      • 認証コントローラーの作成（ログイン / ログアウト）
      • 認証サービスの作成（認証ロジックの分離）
      • セッション管理ミドルウェアの実装
      • エラーハンドリングの実装
      • テストコードの作成
  • Step 2：計画をレビュー
    • 各コンポーネントの責務が明確か
    • 実装順序が適切か
    • 要件に漏れがないか
  • Step 3：Agentモードで段階的に実装
    • プロンプト

      $ Step 1の計画に基づいて、
      まず認証コントローラーを作成してください。
      ログインとログアウトのエンドポイントを実装し、
      認証サービスを呼び出すようにしてください。

  • このように1ステップずつ実装 → 動作確認を繰り返すことで、実装の破綻を防ぎやすくなる。

4.3. メリット

• コードの質が安定しやすい
  • 一貫性のあるコードが生成されやすい
  • 責務の分離が適切に行われやすい
• 修正が容易
  • 問題箇所の特定が早い
  • 影響範囲が明確
• レビューが効率的
  • 実装前後で設計と照合できる
• チーム開発での共有が容易
  • 認識合わせがしやすい
  • 実装方針が明確になる

5. よくある失敗パターン

Planモードを理解していても、実践では様々な失敗をしてしまいます。
ここでは、よくある失敗パターンとその回避方法を紹介します。

失敗パターン1：PlanなしでAgentに投げる

• 症状
  • Agentモードに複雑なタスクを丸投げ
  • 生成されたコードが期待と違う
  • 修正に時間がかかる

  • 例：
    「ユーザー管理機能を実装して」
    → 認証、認可、プロフィール管理が混在
    → 後から分離するのに時間がかかる
            

• 回避方法
  • 複雑なタスクは必ずPlanモードで設計を固める
  • 「このタスクは1ファイルで完結するか？」を自問する
  • 設計が不明確ならPlanモードを使う

失敗パターン2：計画を過信する

• 症状
  • Planモードで作成した計画を絶対視
  • 実装中に問題が発見されても計画を修正しない
  • 柔軟性を失う

  • 例：
    Planで「A → B → C」の順序を決めた
    → 実装中に「Bの前にDが必要」と判明
    → でも計画を変えずに進めて、後で大修正
            

• 回避方法
  • 計画は「仮説」として扱う
  • 実装中に問題が発見されたら、すぐに計画を見直す
  • Planモードは何度でも使える

失敗パターン3：計画が細かすぎる

• 症状
  • 計画が細かすぎて、実装の柔軟性を失う
  • 計画作成に時間がかかりすぎる
  • 実装中に微調整できない

  • 例：
    Planで「1行目のコードはこう、2行目はこう...」と詳細に指定
    → 実装中に「この方法の方が良い」と気づいても変更できない
    → 計画に縛られて非効率
            

• 回避方法
  • 計画は「何を」「なぜ」を明確にし、「どう」は大まかに
  • 実装の詳細はAgentモードに任せる
  • 計画の粒度は「コンポーネント単位」程度が適切

失敗パターン4：Planモードを過度に使う

• 症状
  • 単純なタスクでもPlanモードを使う
  • 計画作成に時間がかかり、効率が悪い
  • 「計画を作るのが目的」になってしまう

  • 例：
    「変数名を変更する」という単純なタスクでもPlanモードを使う
    → 計画作成に5分、実装に1分
    → 直接Agentモードで1分で終わるタスクを6分かける
            

• 回避方法
  • 単純なタスクはAgentモードを直接使う
  • 「このタスクはPlanが必要か？」を判断する
  • 計画作成の時間もコストとして考える

失敗パターン5：計画をレビューしない

• 症状
  • Planモードで計画を作成したら、すぐにAgentモードで実装
  • 計画の妥当性を確認しない
  • 実装後に「計画が間違っていた」と気づく

  • 例：
    Planで「認証はJWTで実装」と計画
    → レビューせずに実装開始
    → 実装後に「セッション管理が必要」と判明
    → 最初からやり直し
            

• 回避方法
  • 計画を作成したら、必ずレビューする
  • 「この計画で本当に要件を満たせるか？」を確認
  • チーム開発では計画を共有してレビュー

失敗パターン6：Askモードを活用しない

• 症状
  • コードベースを理解せずにPlanモードで設計
  • 既存の実装と整合性が取れない
  • 重複実装や不整合が発生

  • 例：
    既存の認証実装を確認せずにPlanモードで設計
    → 既存の認証方式と異なる方式を提案
    → 実装後に不整合が発覚
            

• 回避方法
  • 新しいタスクに取り組む前に、Askモードで既存コードを理解する
  • 既存の設計パターンや規約を確認する
  • Planモードで設計する際も、既存実装との整合性を考慮する

6. まとめ

この記事では、Cursorの4つのモード（Ask / Agent / Plan / Debug）について、 特にPlanモードに焦点を当てて解説しました。

「いきなり書かせる」のではなく、「設計してから書かせる」。
この意識を持つだけで、Cursorとの付き合い方が大きく変わる可能性があります。
ぜひ、Planモードを活用して、より効率的で質の高い開発を実現してみてください。
最後までお付き合いいただきありがとうございました。

1. はじめに：顧客データ活用が進まない
2. AIエージェントを利用した顧客データ活用環境（Amazon Bedrock）
3. AIエージェントで顧客データを分析する
4. まとめ：スモールスタートで始める顧客データ活用

1.はじめに：顧客データ活用が進まない

「顧客データをもっと活用したい」という声をよく耳にします。購買データ、会員データ、来店履歴、キャンペーンの反応率など、日々さまざまなデータが蓄積されていますが、それらを活用して顧客理解を深め、顧客体験の向上や販促施策に結びつけていくことは簡単ではありません。

データが複数のシステムに散らばっていたり、分析担当者が不足していたり、情報システム部も本業の対応で忙しく、すぐに動けない場合もあります。「どこから手をつけたらいいかわからない」という状況のまま、時間だけが過ぎてしまうこともあります。

しかし、顧客データ活用が重要であることは間違いありません。そこでAWSが公開しているサンプルソリューションを活用することで、データ活用の最初の一歩を驚くほど軽やかに踏み出すことができます。

本記事では、主に小売業の皆さま向けに、「顧客データ活用の最初の一歩をどう簡単に始められるのか」をご紹介します。 今回ご紹介のデモンストレーションは小売業のシナリオですが、もちろん小売業以外でも営業・販売促進（マーケティング）・企画...といった職種の方々にお役に立てる内容です。また、「データ収集・加工・分析の依頼が多い...。」といったIT部門の方々の課題解決にもなります。 少しでも多くの皆様の参考になれば嬉しいです。

2.AIエージェントを利用した顧客データ活用基盤（Amazon Bedrock）

2-1. データ活用のはじめの一歩

今回はAWSが公開している下記リポジトリを利用します。
https://github.com/aws-samples/sample-c360-text2sql-segmentation-entityresolution　

デプロイは簡単で、AWSが提供しているWebページにてDeployボタンを押下するだけで、任意AWSアカウントに以下「AIエージェントを利用した顧客データ活用環境」を構築することができてしまいます。

構築手順概要

1. AWSアカウントを用意してログインする
2. 下記WebページにおいてDeployボタンを押下する
https://aws-samples.github.io/sample-one-click-generative-ai-solutions/solutions/c360/

3. S3バケットにサンプルデータをアップロードする
4. Cognitoユーザプールでログイン認証情報を設定する

※上記はサンプルデータを活用する手順です。オリジナルデータを活用するには、別途手順を踏む必要があります。

2-2.具体的にAIエージェントは何をしてくれるの？

上記構成において、AIエージェントはデータ分析に使用する下記のようなSQL文を作成してくれます。例えば、チャットに「20代女性が頻繁に購入する商品、および購入される時期を教えてください。」と投げかけると、下記のような複雑なSQL文が一瞬で作成されます。

 
WITH twenties_female_customers AS (
  SELECT customer_id
  FROM customer_master
  WHERE gender = 'female' AND age >= 20 AND age < 30
)

SELECT 
  im.item_id,
  im.item_name,
  im.item_category,
  im.item_style,
  COUNT(*) as purchase_count,
  DATE_FORMAT(from_unixtime(ph.purchase_date), '%Y-%m') as purchase_month,
  COUNT(DISTINCT ph.customer_id) as unique_customers
FROM purchase_history ph
JOIN twenties_female_customers tfc ON ph.customer_id = tfc.customer_id
JOIN item_master im ON ph.item_id = im.item_id
GROUP BY 
  im.item_id, 
  im.item_name, 
  im.item_category, 
  im.item_style, 
  DATE_FORMAT(from_unixtime(ph.purchase_date), '%Y-%m')
ORDER BY purchase_count DESC
LIMIT 20;

 

今までは、複雑なSQL文作成を情報システム部に依頼していたかもしれません。それでは、コミュニケーションコストや作業工数がかさんでしまいます。これからは、AIエージェントがSQL文を自動生成してくれるので、他部署とのコミュニケーションコストや全体的な作業工数を低減していくことができます。
また、AIエージェントは下記役割も果たしています。

今までは、作成されたSQL文を分析ツール（Athena）に手動で流す必要や、出力結果を業務に使いやすい形にブラッシュアップする必要がありました。これからは、データ分析から要約までAIエージェントが対応してくれるので、業務効率が一層上がると思われます。
結果として、ビジネス部門が自走できる組織づくりを支援してくれるのです。

2-3.データベース層にはどんなデータが入っているの？

ここで使用しているテストデータを紹介いたします。今回は下記のようなCSV形式の顧客データをS3に格納しています。

本構成においては、S3に蓄積された顧客データをGlueで構造化していくことで、AIエージェントやSQLからすぐに活用できる分析基盤を構築しています。

3.AIエージェントで顧客データを分析する

AIエージェントを利用した顧客データ活用環境の構築ができれば、顧客データが分析できる状態まで整います。

3-1.どうやってAIエージェントを使えるの？

これまで、小売の現場で売上や購買傾向を調べるには、多くの手順が必要でした。期間を指定し、商品カテゴリごとに抽出し、必要であれば顧客データと結びつけ、場合によってはエンジニアに依頼して結果が出るまで待つこともありました。
しかし、AIエージェントを使うと、自然な言葉で質問するだけで答えが返ってきます。 例えば次のような会話が可能になります。

AIエージェントと会話ベースでのやりとり

質問すれば、意図に沿った情報に答えてくれるというのはとても魅力的です。
これまでは数日かかっていた問いが、わずか数秒で返ってくるだけではありません。すぐに次の問いが思い浮かぶようになります。
「では、その商品を購入している人のリピート率は？」
「購買が増える時間帯は？」
「他に一緒に買われている商品は？」
「天候との関係は？」
このように、問いが連鎖することで、現場の意思決定スピードが大きく向上します。

3-2.AIエージェントを使うメリット

こうした即時性のある分析が可能になると、現場だけでなく、情報システム部にとっても良い変化が生まれます。これまで情報システム部は、現場から依頼される「このデータを抽出してほしい」、「この条件で分析してほしい」といった作業に多くの時間を割いていました。依頼内容を確認し、必要なデータを探し、整形し、加工し、レポートとしてまとめるという一連の作業は、本来の業務とは別の大きな負担でした。
一方、ビジネス側も同じです。データを収集し、条件を合わせ、形式を整えるだけで多くの時間がかかり、肝心の分析や戦略検討に十分な時間を割けないという悩みがありました。しかし、AIエージェントが活用できる環境が手に入ると、こうした負担が大きく軽減されます。現場は、自分たちの言葉で質問し、その場で必要な情報を手にすることができます。
情報システム部は、繰り返し発生する抽出作業から解放され、より価値の高い本来の業務に時間を使えるようになります。 つまり、双方が本来注力すべき仕事に集中できるようになり、企業全体としての意思決定の質とスピードが大きく向上するのです。

例えば、以下のような活用方法が考えられます。
(1)販促担当：キャンペーンの効果測定
(2)インストラクター: 会員一人ひとりに合わせたケア計画
(3)EC事業担当：実績を固定帳票とは違う切り口で分析
(4)小売店の店⻑：固定帳票を読み解けない経験の浅いスタッフの補助
(5)顧客分析担当：顧客のRFM分析（※1）、デシル分析(※2）、店舗エリア別分析etc
(6)経営戦略部：顧客データを活用した各事業の経営戦略

※1　RFM分析⋯顧客の購買データをRecency（最終購入日）、Frequency（購入頻度）、Monetary（購入金額）の3つの指標で評価し、顧客をグループ分けして最適なマーケティング施策（優良顧客への特別オファー、離反顧客へのアプローチなど）を打つための顧客分析手法
※2　テシル分析⋯顧客の購買データをもとに、購入金額の高い順に顧客全体を10等分（デシル＝10分の1）し、各グループ（デシル1～10）の売上構成比や1人あたりの購入金額を分析する手法

情報システム部→AIエージェント

4.まとめ：スモールスタートで始める顧客データ活用

顧客データ活用は、大きな投資や大規模なプロジェクトが必要というイメージを持たれがちですが、実際には、サンプルソリューションを使ってまず体験してみることから始めることができます。複雑な準備や専門知識は不要で、必要なのは「やってみたい」という前向きな気持ちだけです。
アクセルユニバースでは、それぞれの小売企業が抱えている課題や状況に合わせて、サンプルソリューションのデモをご用意することができます。操作方法や仕組みについても、わかりやすい形で丁寧にご説明します。

また、「自社のデータならどう使えるのか」、「導入するとどこに効果がありそうか」といった疑問にも寄り添いながら、一緒に解像度を上げていくことができます。まずは、小さく触れてみることから始めてみませんか。顧客データ活用は、体験することで一気に実感できるようになります。気になる点や不安な点があれば、どんなことでもお気軽にご相談ください。

AUCへのお問い合わせ　

サンプルソリューションのデモ視聴希望の方はこちら　

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. 1. はじめに
2. 2. DifyでエージェントとMCPサーバーを使ってみよう
3. 　2-1. MCPサーバーの設定
4. 　2-2. エージェントチャットでMCPサーバーを使う
5. 　2-3. ワークフローでエージェントとMCPサーバーを使う
6. 3. まとめ
7. 4. Difyのそれは極めて個人的な考察

      貴方はGithubリポジトリ「McpBlogSample」の管理者です。

      [McpBlogSampleリポジトリ]
      https://github.com/t-ogawa-dev/McpBlogSample

      ユーザから与えられたリポジトリへの指示を適切に行ってください。
    

      新しいIssue「デザインを赤基調から緑基調に変更」を作成してください。
      またコメント欄には必要と思われる内容を記載してください。
    

      あなたは GitHub リポジトリ「McpBlogSample」の管理者兼メンテナーです。

      対象リポジトリ：
      https://github.com/t-ogawa-dev/McpBlogSample

      ユーザーから渡された Issue ID の Issue情報を取得し、
      内容を要約してください。
    

      Issue ID: {{input.issue_id}} ←※ 「/」を入力すると変数選択メニューが表示されますので、そこから選択する
    

1. 1. はじめに
2. 2. Difyとは
3. 3. Difyの基本操作
4. 　3-1. Difyの種類
5. 　3-2. アカウント作成
6. 　3-3. シンプルなワークフローを作ってみる
7. 4. Dify実践: LLMとの連携
8. 　4-1. 初期設定(LLM設定)
9. 　4-2. ワークフローでLLMを使ってみる
10. 5. まとめ

 
1. 1. はじめに
2. 2. OSS MCPサーバーを使ってみよう
3. 　2-1. 準備フェーズ
4. 　　①OSS MCPサーバーをGitHubからダウンロード
5. 　　②OSS MCPサーバーを構築
6. 　　③VS CodeにMCPサーバー情報を設定
7. 　　④動きませんでした。そしてその対策。
8. 　2-2. 実行フェーズ
9. 　　①Agentを実行しよう
10. 　　②実行ログを見て、通信の動きを確認しよう
11. 3. まとめ
12. 4. MCPサーバーのそれは極めて個人的な考察

はじめに

Amazon Web Services（AWS）が2025年11月30日に「AWS MCP Server」をプレビュー版として公開しました！

参照：AWS announces a preview of the AWS MCP Server

「本番VPC作っておいて。」とAIエージェントに指示を出せば、AWSコンソールやCLIを触ることなく適切な設定で本番VPCがデプロイされる・・・ころころと変わる画面仕様やAPI仕様にエンジニアが右往左往する時代はもう終わり！！そんな未来が近づいているのかもしれません。

「AWS MCP Server」は、自然言語を通じてAIアシスタントやエージェントに対し指示を出すと、安全にベストプラクティスに従った形に整形された状態でAWS APIを呼び出すことを可能にした、リモートMCPサーバーです。

この記事では、AWSを利用する開発者、インフラエンジニア、そして技術的な意思決定者の皆様向けにAWS MCP Serverの機能と利点をざっくり解説していきます。

基本の確認：MCPサーバーとは何か？

AWS MCP Serverを理解するためには、まずその基盤技術である「MCP（Model Context Protocol）」および「MCPサーバー」の基本概念を整理する必要があります。

MCPとは、「AIモデルが外部のツールやサービスと連携するための共通規格（プロトコル）」です。

MCPの仕組みや導入メリット・デメリットに関して確認したい、という方は当社のこちらのブログ記事をぜひご覧ください。

参照：実体験でわかったMCPサーバー・クライアントの役割と導入メリット

AWS MCP Serverの核心機能

「はじめに」で触れた通り、「AWS MCP Server」は、自然言語を通じてAIアシスタントやエージェントに対し指示を出すと、安全にベストプラクティスに従った形に整形された状態でAWS APIを呼び出すことを可能にした、リモートMCPサーバーです。

実は元々「AWS Knowledge MCP」（知識を呼び出すためのMCPサーバー） および AWS API MCP（機能を呼び出すためのMCPサーバー）が存在していましたが、今回の「AWS MCP Server」により、ひとつの窓口（リモートMCPサーバー）で「知識の呼び出し」と「機能の呼び出し」を行えるようになります。

AWS MCP Serverでは、以下の３つの機能が提供されています。

• エージェントSOP（Agent SOPs）

AIエージェント用の「標準作業手順書」の意味です。

エージェントSOPが用意されていることで、AIアシスタントがAWSのベストプラクティスとセキュリティガイドラインに従って、複雑な複数ステップのタスクを完了できるようになります。

ただ「AIエージェントがAWSのAPIを呼び出せる」だけでは「安全」とは言えません。自然言語の指示に従って無限の可能性の中からAIアシスタントがどのAPIを使うか勝手に判断するのではなく、エージェントSOPという、十分に検証された、信頼できる選択肢の中から最適なものを選択することで、セキュアでベストプラクティスに沿ったAWS上のリソース構築・運用を行うことができます。

用意されているエージェントSOPの例としては本番環境対応VPN（マルチAZサブネットとNATゲートウェイを備えた構成）作成ワークフローやモニタリング（CloudWatchアラームとSNS）設定、Amplifyを利用したWebアプリケーションの構築・デプロイなどの例があげられていました。

詳しくは公式ドキュメントをご参照ください。

具体的にこうしたい、という指示ができない場合、エージェントに現在利用可能なツール（ワークフロー）を使って計画を立てて、と依頼して対話型で設計を検討することもできるそうです。心強い！

また、どんなSOPが用意されているのかもエージェントに聞いて確認することができます。

• ナレッジツール（Knowledge Tools）

本番環境におけるAIの「ハルシネーション（誤った情報をそれっぽく回答してくるやつのこと）」リスクを低減させるための重要な機能です。

最新のAWS公式ドキュメント、APIリファレンス、リージョン別のサービス提供状況などをリアルタイムで検索・参照することで、AIの応答の正確性を向上させます。参照元が確実であることから、安心度がアップしますね。

• APIツール（API Tools）

自然言語による指示を、適切なAWS APIコールへと変換し実行する機能です。セキュリティ・ガバナンスの点で最も重要なのが、AWS APIコールは対象のAWSアカウントのIAM認証情報を用いて実行される点です。AWS APIコールは当然CloudTrailに記録され証跡が残りますし、実行できる権限を最小権限の原則に従い制限しておくことで、安全にAIエージェントを利用することができます。

AWS MCP Server：何が嬉しい？！

AWSサービスは、増えたり統合されたり廃止になったりと目まぐるしく変化しています。毎日のように新情報がリリースされ、ベストプラクティスもどんどん更新されます。開発者は大量のブラウザタブを開きながらドキュメントを読み漁り、「この構成で本当に安全？」「最新のガイドラインと合ってる？」と不安を抱えつつ設計を進めなくてはいけませんでした。調べる、比べる、検証する......その繰り返しで、実装より調査に時間が吸い取られることも多いのではないでしょうか。（私はそうです・・・）

そんな長年の悩みに対して、AWS MCP Serverはとても心強い存在になりそうです。「こういう仕組みを作りたいんだけど」と自然言語で相談すると、AIアシスタントが最新のAWSドキュメントを横断検索し、関連サービスを整理し、適切な設計方針までまとめてくれます。必要であれば具体的なAPI操作も実行してくれて、作業が一つの画面の中で完結します。人間側は適宜承認するだけでよく、迷いながら進めていたAWS設計が一気にクリアになります。

すべてが完全自動になるわけではないかもしれませんが、「とにかく情報を追うのが大変」「正解がどれか自信が持てない」といったこれまでの大きな悩みが、かなり軽くなる未来は感じられると思います。まだPreview版のためか、re:Inventのキーノートでは触れられませんでしたが、今後のAWS管理を大きく変える可能性のある機能と感じます。ぜひ活用していきたいですね！

最後の最後に・・・怠惰な私の願望としては、もはやMCPサーバーを呼び出すためのセットアップすら面倒なので、マネジメントコンソール上でCloudFormationあたりにチャットウィンドウが用意されていて、そこから相談や作成指示ができたりしたらもっと嬉しいです！！

• はじめに
• 1. AWS AI Factories とは：AI 運用の課題をまとめて解決する新モデル
• 2. AWS AI Factories を構成する要素
• 3. AWS AI Factories がもたらす企業メリット
• さいごに

はじめに

今年もラスベガスにて、世界最大級のクラウドカンファレンス「AWS re:Invent 2025」が開催されました。
今年のre:InventではAIに関するサービスのアップデートが中心となっており、「AWS AI Factories」という新サービスが発表されました。
生成AIがビジネスのあらゆる領域に浸透する一方で、企業が直面している課題は「どのように安全かつ継続的に AI を運用していくか」という点に移っています。
この課題を解決するための新しいコンセプトが、AWS AI Factories です。

AWS AI Factories は、AIモデルの開発・運用・継続改善を、まるで工場の生産ラインのように統合的に管理できる"AI ライフサイクル基盤"と位置づけられています。従来の AI/ML パイプラインを置き換えるものではなく、それらをさらに高度化・運用最適化した仕組みと捉えると理解しやすいかと思います。

1. AWS AI Factories とは：AI 運用の課題をまとめて解決する新モデル

多くの企業が PoC では成功しながら、本番運用に移せない理由がいくつかあります。
代表的な例として、

• モデルの更新が属人化し、継続改善できない
• データの扱いにガバナンスが追いつかない
• セキュリティ・監査要件に対応できない
• 複数部門での AI 利活用が標準化されていない
• ツールやプロセスが分断し、効率が悪い

2. AWS AI Factories を構成する要素

AWS AI Factories は、以下のような要素で構成されます。

● データ管理（Data Factory）
データの収集、前処理、品質管理を自動化し、モデル改善につながるデータ基盤を整備。

● モデル運用（Model Factory）
モデル学習、評価、デプロイ、ドリフト検知を自動化し、継続的な高品質運用を実現。

● ガバナンス & セキュリティ（Guard Factory）
アクセス管理、監査ログ、コンプライアンスチェックなど、企業が求める統制を一元化。

● 利活用フロント（App Factory）
開発者・業務ユーザーが AI/アプリを安全に利用できる環境を整え、現場でのスピード活用を後押し。


これらの要素が連携することで、AIの価値を継続的に引き出せる"循環型AI基盤"が構築されます。

3. AWS AI Factories がもたらす企業メリット

① AIの運用を標準化し、スケール可能にする
企業全体で同じ基盤を使うことで、部門ごとにバラバラだった AI 活用を統合できる。

② 安全性・コンプライアンスを担保
生成AI導入の最大の懸念であるデータ漏えい・アクセス管理・監査要求に対応しやすい。

③ 継続的改善（Continuous Learning）が自動化
データ流入 → モデル改善 → 再デプロイまでのサイクルが回り続け、AIが常に最新状態を保つ。

④ 業務部門でも AI 活用が可能に
ローコード化／プロンプト管理／アプリ統合により、エンジニア不足でもAI活用が進む。

さいごに

生成AIが進化を続ける一方で、企業が求められるのは単なる技術導入ではなく「どうAIを安全かつ継続的に運用し、価値を最大化するか」です。AWS AI Factories はまさにその解答となるアーキテクチャです。
AIは一度導入して終わりではなく、改善を続けることで真価を発揮します。AWS AI Factories は、AIを企業の"当たり前の基盤"として育てるための仕組みであり、今後のAI戦略を考える上で重要な役割を担うことが予測されます。

1. 1. はじめに
2. 2. Zapier MCPサーバーを使ってみよう
3. 　2-1. 準備フェーズ
4. 　　①Zapierでアカウントを作成
5. 　　②ZapierでMCPサーバーを構築
6. 　　③VS CodeにMCPサーバー情報を設定
7. 　2-2. 実行フェーズ
8. 　　①Agentを実行しよう
9. 　　②Zapierの実行履歴(History)を確認しよう
10. 3. まとめ

1. 1. はじめに
2. 2. 公式GitHub MCPサーバーを使ってみよう
3. 　2-1. 準備フェーズ
4. 　　①GitHubでPersonal Access Tokenを作成
5. 　　②VS CodeにMCPサーバ情報を設定
6. 　　③作業対象のサンプルプロジェクトを作成
7. 　2-2. 実行フェーズ
8. 3. まとめ

1. 1. はじめに
2. 2. MCPとは(一般論)
3. 3. 実際に触ってわかったこと: よくある誤解
4. 　3-1. MCPサーバーの誤解
5. 　3-2. MCPクライアントの存在
6. 4. MCPを導入する前に知っておくべきこと
7. 　4-1. 実現できること
8. 　4-2. リスクと注意点
9. 5. まとめ
10. 6. おまけ：現状と今後の展望についての極めて個人的な考察
11. 7. 参考資料

目次

1. はじめに
2. 環境構築
3. AI に実装を依頼する
4. 所感
5. まとめ

1. はじめに

こんにちは。エンジニアの齋藤です。

昨今のSNSでは、ChatGPTやClaudeを使ってアプリを作ったという報告を目にすることがあります。一方で、「どんな手順で進めればいいのか」「どこまでAIに任せて、どこから自分で考えるべきか」 といった具体的なプロセスについては、まだ体系的な情報が少ないように感じます。

本記事では、Apple が Xcode 26 で導入した Claude統合機能 を活用し、実際にTODO管理アプリを作る過程を通じて、AIを使った開発の実態を具体的に解説 します。非エンジニアの方でも実践できるよう、環境構築から完成まで、すべてのステップを詳細に記載しました。

AI開発の可能性を体感していただくことで、チームの生産性向上や新規事業の迅速な検証といった、新しいアプローチのヒントを得ていただければ幸いです。

1-1. この記事で分かること

• Claude統合機能を利用したiOSアプリ開発環境の構築手順
• 非エンジニアでも理解できる開発フロー
• 実際に使えるTIPS

1-2. この記事では割愛すること

• Swift/SwiftUIの詳細な文法説明
• UIデザインの詳細
• App Storeへの公開手順
• CLAUDE.mdなどを利用したチーム開発での運用

1-3. 対象読者

• 非エンジニア: 自分でもアプリ開発してみたい方
• iOS開発初心者: AI支援機能を利用してiOS開発を学習したい方
• iOSエンジニア: 最新のAI支援開発を体験したい方
• プロジェクトマネージャー: AI開発の実態を把握したい方

1-4. 今回作成するアプリ

シンプルなTODO管理アプリを作成します。

主な機能

• TODO の作成・編集・削除
• 完了/未完了の切り替え
• 期日設定と期限アラート(色分け表示)
• ステータス管理(未着手/処理中/作業完了/完了)
• ドラッグ&ドロップでの並び替え
• データの永続化(アプリを閉じても保存)

所要時間
約 2〜3 時間(環境構築含む)

2. 環境構築

今回の検証に利用したMac、およびツールのスペックは以下の通りです。

2-1. Xcode のインストール

1. App Storeアプリ を開く
2. 検索で「Xcode」を入力
3. 「入手」をクリック
4. ダウンロード完了まで待つ (10GBほどあるため、回線速度によっては30分ほどかかる場合があります)

2-2. Claude統合機能 の設定

Xcodeを起動して、設定画面を開く

1. メニューバーから Xcode > Settings... をクリック(⌘,)
2. 設定ウィンドウが開きます
3. 左メニューのIntelligenceを選択

Claudeアカウントでログイン

1. 「Sign In...」をクリックして、お手持ちのClaudeアカウントで認証してください
2. 接続要求の画面が表示されたら、「承認する」をクリック

2-3. プロジェクトの作成

新規プロジェクトを作成

1. Xcode を起動
2. "Create New Project" をクリック
3. テンプレート選択画面で:
   • iOS を選択
   • App を選択
   • Next をクリック

プロジェクト設定

以下の項目を入力します:

※ Organization Identifier は逆ドメイン形式(com.会社名.アプリ名)が一般的ですが、個人開発なら jp.yourname.SampleTodoApp のような形式で問題ありません。

プロジェクトの保存先を選択

1. 任意のフォルダを選択
2. "Create Git repository" にチェック(バージョン管理用、推奨)
3. Create をクリック

これでプロジェクトが作成され、Xcode のメイン画面が開きます。

3. AI に実装を依頼する

ここから実際に実装していきます。直接コードを書かずに アプリを完成させます。

3-1. 開発フロー

下記の開発フローで進めます。
肝は、要件定義をもとに全体を一括実装したあとに、個別に細かい部分を修正していくというところになります。

1. 要件定義(必要に応じて設計レベルまで)を作成する
2. 前段で作成した要件定義をXcodeのCoding Assistantに読み込ませる
3. Coding Assistantがコードを自動生成
4. シミュレータで実行
5. エラーや想定と異なる箇所があれば、個別にCoding Assistant経由でコードを修正

3-2. 要件定義の作成

まずは、作りたいアプリの要件を整理します。これが最も重要なステップです。

※ 重要: 要件定義の作成自体も、生成AI(ClaudeやChatGPT)を積極的に活用しましょう。アイデアを箇条書きで伝えるだけで、AIが構造化された要件定義を作成してくれます。

要件定義の作り方

アイデアを簡単に箇条書きする

まず、作りたいアプリのイメージを箇条書きで整理します:

作りたいアプリ: TODO管理アプリ

基本的な機能:
- TODOの追加・編集・削除
- 完了/未完了の管理
- 期限の設定
- 並び替え

欲しい機能:
- ステータス管理(未着手、処理中など)
- 期限が近いTODOを色分け表示
- データはアプリを閉じても保存される

AIに要件定義の作成を依頼

上記の箇条書きを Claude に渡して、要件定義書を作ってもらいます:

以下のアイデアをもとに、iOSアプリ開発用の詳細な要件定義書を作成してください。

【要件定義書に含めてほしい項目】
- アプリ概要
- 機能要件(画面ごとに整理)
- UI/UX仕様
- データ管理(データモデル、永続化方法)
- 技術仕様
- 画面フロー
- ファイル構成

【アイデア】
[上記の箇条書きを貼り付け]

SwiftUIを使用したネイティブiOSアプリとして実装したいです。

生成された要件定義を確認・修正

AIが生成した要件定義を確認し、必要に応じて修正を依頼します:

要件定義ありがとうございます。
以下の点を修正してください:

- ステータスは4段階(未着手/処理中/作業完了/完了)にしたい
- 期限が過ぎたTODOは赤、3日以内は橙色で表示したい
- ドラッグ&ドロップで並び替えできるようにしたい

このように、対話しながら要件定義を磨き上げることで、非エンジニアでも実装可能なレベルの詳細な仕様書が完成します。

完成した要件定義のサンプル

上記のプロセスで作成された要件定義の例を以下に示します:

# SampleTodoApp 要件定義書

## 1. 概要

### 1.1 アプリケーション名
SampleTodoApp

### 1.2 目的
日々のタスクを効率的に管理するためのTODO管理アプリケーション。作成、編集、削除、ステータス管理などの基本機能を備えたiOSネイティブアプリケーション。

### 1.3 対象プラットフォーム
- iOS（SwiftUI使用）

---

## 2. 機能要件

### 2.1 TODO一覧表示機能

#### 2.1.1 基本表示
- TODOアイテムをリスト形式で表示
- 各アイテムに以下の情報を表示：
  - タイトル
  - 完了/未完了チェックボックス
  - ステータスバッジ（カラー付き）
  - 作成日
  - 期日（設定されている場合）

#### 2.1.2 空状態
- TODOが0件の場合、空状態画面を表示
- メッセージ：「TODOがありません」
- システムアイコン：checklist
- 説明文：「右上の + ボタンで新しいTODOを追加してください」

#### 2.1.3 期日表示の色分け
- **赤色**：期日超過
- **オレンジ色**：期日まで3日以内
- **グレー色**：通常（4日以上先）

#### 2.1.4 完了済みアイテムの表示
- タイトルに取り消し線を表示
- チェックマークアイコンを緑色で表示
- テキストカラーをセカンダリカラーに変更

### 2.2 TODO追加機能

#### 2.2.1 入力項目
**基本情報セクション：**
- タイトル（必須）：テキストフィールド
- ステータス：ピッカー（デフォルト：未着手）

**日付セクション：**
- 作成日：日付ピッカー（デフォルト：現在日時）
- 期日設定トグル
- 期日：日付ピッカー（トグルON時のみ表示、作成日以降の日付のみ選択可能）

**説明セクション：**
- 説明：テキストエディター（複数行入力可能、高さ150〜200pt）

#### 2.2.2 バリデーション
- タイトルが空の場合、保存ボタンを無効化
- 保存ボタンの背景色を変更（無効時：グレー、有効時：ブルー）

#### 2.2.3 UI構成
- ナビゲーションタイトル：「新規TODO」
- キャンセルボタン（左上）
- 保存ボタン（画面下部固定、フルワイド）
- スクロール可能なフォーム部分

### 2.3 TODO編集機能

#### 2.3.1 編集可能項目
- タイトル
- ステータス
- 期日（設定/解除/変更）
- 説明

#### 2.3.2 編集不可項目
- 作成日（表示のみ、グレーアウト）

#### 2.3.3 UI構成
- ナビゲーションタイトル：「TODOを編集」
- キャンセルボタン（左上）
- 削除ボタン（右上、赤色のゴミ箱アイコン）
- 保存ボタン（画面下部固定）

#### 2.3.4 削除機能
- 削除ボタンタップ時、確認アラートを表示
- アラートメッセージ：「『[タイトル]』を削除しますか？この操作は取り消せません。」
- ボタン：「キャンセル」「削除」（破壊的アクション）

### 2.4 TODO操作機能

#### 2.4.1 完了/未完了切り替え
- チェックボックスタップで即座に状態を切り替え
- アニメーション付きで表示を更新

#### 2.4.2 並び替え
- 編集モード時にドラッグ&ドロップで順序変更可能
- 変更内容は自動保存

#### 2.4.3 削除
- スワイプ削除に対応
- 編集モード時の削除ボタンにも対応

#### 2.4.4 詳細表示
- リストアイテムタップで編集画面へ遷移

### 2.5 データ管理機能

#### 2.5.1 データ永続化
- UserDefaultsを使用してデータを保存
- JSON形式でエンコード/デコード

#### 2.5.2 自動保存タイミング
- TODO追加時
- TODO更新時
- TODO削除時
- TODO並び替え時
- 完了状態変更時

---

## 3. データモデル

### 3.1 TodoItem構造体

```swift
struct TodoItem: Identifiable, Codable {
    let id: UUID                // 一意識別子
    var title: String           // タイトル（必須）
    var isCompleted: Bool       // 完了フラグ
    let createdAt: Date         // 作成日時
    var dueDate: Date?          // 期日（オプショナル）
    var description: String     // 説明
    var status: TodoStatus      // ステータス
}
```

### 3.2 TodoStatus列挙型

4つのステータスを定義：

| ステータス | 表示名 | カラー | 
|-----------|--------|--------|
| notStarted | 未着手 | グレー |
| inProgress | 処理中 | ブルー |
| workCompleted | 作業完了 | オレンジ |
| completed | 完了 | グリーン |

---

## 4. UI/UX要件

### 4.1 画面構成

#### 4.1.1 一覧画面（ContentView）
- NavigationView構造
- ツールバー：
  - 左側：編集ボタン（日本語表示）
  - 右側：追加ボタン（+アイコン）
- リスト表示エリア
- 上部セーフエリアに16ptのスペーシング

#### 4.1.2 追加/編集画面
- NavigationStack内でシート表示
- ScrollView + Form構造
- 固定された下部ボタンエリア
- フォーム最小高さ：700pt

### 4.2 カラースキーム
- システムカラーを使用（ダークモード対応）
- ステータスバッジの背景：対応カラーの10%透明度
- 保存ボタン有効時：ブルー
- 保存ボタン無効時：グレー
- 削除ボタン：レッド

### 4.3 アクセシビリティ
- EditButtonにロケール設定（ja_JP）を適用
- 日付フォーマットは日本語形式（yyyy/MM/dd）

---

## 5. 技術要件

### 5.1 開発環境
- 言語：Swift
- フレームワーク：SwiftUI
- アーキテクチャ：MVVM
- 非同期処理：Swift Concurrency（MainActor使用）

### 5.2 使用技術
- **データバインディング**：@Published, @StateObject, @ObservedObject
- **ナビゲーション**：NavigationView, NavigationStack
- **モーダル表示**：Sheet
- **状態管理**：@State, @Environment
- **データ永続化**：UserDefaults + Codable

### 5.3 ViewModel（TodoViewModel）
- @MainActorで宣言（UIスレッドで実行）
- ObservableObjectプロトコル準拠
- 提供メソッド：
  - `addTodo()` - TODO追加
  - `updateTodo()` - TODO更新
  - `deleteTodo()` - TODO削除
  - `moveTodo()` - TODO並び替え
  - `toggleCompletion()` - 完了状態切り替え

---

## 6. 制約事項

### 6.1 データ保存
- UserDefaultsを使用するため、大量データには不向き
- データ容量制限に注意

### 6.2 日付選択
- 期日は作成日以降の日付のみ選択可能
- 作成日は編集不可

### 6.3 バリデーション
- タイトルが空の場合は保存不可

---

## 7. 今後の拡張可能性

### 7.1 検討される機能
- カテゴリー/タグ機能
- 検索・フィルター機能
- 優先度設定
- 通知機能（期日アラート）
- iCloudによるデータ同期
- SwiftDataへの移行（より高度なデータ管理）
- ウィジェット対応
- 添付ファイル機能

### 7.2 改善案
- オフライン対応の強化
- パフォーマンス最適化（大量データ対応）
- アニメーション強化
- アクセシビリティの向上（VoiceOver対応など）

---

## 8. 非機能要件

### 8.1 パフォーマンス
- リスト表示：スムーズなスクロール
- データ保存：同期的に実行（データ量が少ないため許容）

### 8.2 ユーザビリティ
- 直感的な操作性
- 即座のフィードバック
- エラー時の適切なメッセージ表示

### 8.3 保守性
- MVVMアーキテクチャによる責務分離
- Codableプロトコルによるシリアライズ処理
- プレビュー機能による開発効率化

---

## 9. ファイル構成

```
SampleTodoApp/
├── SampleTodoAppApp.swift      # アプリケーションエントリーポイント
├── Models/
│   └── TodoItem.swift           # データモデル定義（TodoItem, TodoStatus）
├── ViewModels/
│   └── TodoViewModel.swift      # ビジネスロジックと状態管理
└── Views/
    ├── ContentView.swift        # TODO一覧画面
    ├── AddTodoView.swift        # TODO追加画面
    └── EditTodoView.swift       # TODO編集画面
```

3-3. Claudeへの実装依頼

XcodeのCoding Assistantを表示する

左ペインのCoding Assistantをクリックします

プロンプトを入力

以下のプロンプトをCoding Assistant経由で Claude に送信すると、必要なファイルが自動生成されます。

以下の要件定義に基づいて、SwiftUIでiOS TODO管理アプリを実装してください。

【重要な指示】
1. すべてのファイルを完全な形で出力してください
2. 各ファイルのパス（例: Models/TodoItem.swift）を明示してください
3. 実装の際、適切なフォルダ構成を提案してください
4. すべてのコードにコメントを付けてください（日本語で）
5. エラーハンドリングを適切に実装してください

【要件定義】

[上記の要件定義をそのまま貼り付け]

3-4. ビルドと動作確認

ファイルが生成されたら、いよいよ実行しましょう。

ビルド

⌘ + B (Command + B) を押してビルドします。

エラーが出た場合:

1. Coding Assistantで、Claude に以下のように伝える:

発生しているビルドエラーを解消して。

2. 該当ファイルが修正される
3. 再度ビルドを実行する

※ Coding AssistantがXcode上のエラー情報などを直接読み取るため、エラー内容の添付は不要です

シミュレータで実行

1. Xcode ツールバーでデバイスを選択(例: iPhone 16e)
2. ⌘ + R (Command + R) を押す
3. シミュレータが起動

動作確認

シミュレータが起動すると、自動的にアプリが立ち上がります。
要件定義の仕様をもとに、動作確認を行いましょう。

TODO一覧 (ブランク)	TODO一覧	TODO一覧 (編集)
TODO新規作成画面	TODO編集画面

3-5. 細かい調整

動作確認後、気になる点があれば、Coding AssistantからClaudeに伝えます。

調整例:

現在のアプリでは、期日が表示される位置が少し窮屈です。
TODORowのレイアウトを調整して、期日を右端に表示するように変更してください。

指摘をClaudeへ送信 → Coding Assistantが自動修正 → 確認

このサイクルを繰り返すことで、理想のアプリに近づけます。

4. 所感

今回の開発を通しての所感をまとめます。

4-1. 要件定義が8割

曖昧な要件だと、AIは「推測」で埋めます。後から「これも欲しい」と追加すると、既存コードとの整合性が取れず大幅な修正が必要になる場合もあります。

本記事でも言及しているように、要件定義の作成自体もAIに任せることができます。ぜひ有効活用してください。

悪い例:

TODO管理アプリを作ってください

良い例:

[詳細な要件定義を提示]
- 画面構成(一覧、追加、編集)
- 各画面の具体的な機能
- データ構造(どんな情報を持つか)
- UI/UXの仕様(色分け、アニメーションなど)

4-2. 開発方針と実装規模

今回実装したアプリは比較的小さい規模だったため、「一括実装→修正」の方針を採用しました。
それでは、実装規模が大きくなったときは、どのような開発方針を採るべきでしょうか。
規模に応じて、適切な粒度で実装スコープを分割することが重要そうです。

4-3. スクリーンショットの活用

Claudeは画像解析も可能です。
言葉で説明しづらいUIの改善も、スクリーンショットで伝えることができます。

[アプリのスクリーンショットを添付]

このUIをもっと洗練させてください。
具体的には、余白を増やし、フォントサイズを調整したいです。

5. まとめ

本記事では、非エンジニアでもClaudeを活用すれば、わずか2〜3時間でiOSアプリを開発できることを実証しました。
ここで重要なのは「詳細な要件定義の作成」と「AIへの適切な指示」でした。
非エンジニアにとっても、自らアイデアを形にできる新しい可能性が開かれました。
この機会に、ぜひ他の生成AIサービスも含めて、色々お試しいただけますと幸いです。

1. Gartner社による生成AIのレポート
2. 生成AI導入の進め方
3. まとめ

Gartner社による生成AIのレポート

Gartner社は、データ品質の低さ、リスク管理の不十分さ、コストの増大、ビジネス価値の不明確さなどの理由で、2025年末までに生成AIプロジェクトの30％がPoC以降に中止されるだろうと発表しました。

2024/07/29に発表されたGartner社によるレポート

2024/7/29にシドニーで開催されたGartner Data & Analytics Summit

Gartner Data & Analytics Summitで講演した、Gartner社のRita Sallam氏は、「今までされてきた誇大宣伝の後、各社の経営者は生成AIに実施した投資回収を待ちきれず、生成AIの価値を表明することに苦労しています。生成AIプロジェクトの範囲が広がるにつれて、システム開発・利用に必要な金銭的負担がますます大きくなっています。」と話しました。

Gartner社によると、生成AIは生産性向上・業務効率化のために使用されることが多いですが、会社の利益に結びつけることが難しく、投資判断をしにくい背景があると述べられています。

生成AI導入にかかる費用例

下記はGartner社が発表した生成AI導入にかかる費用例です。プロジェクトの規模に応じてかかる費用は大幅に変動するため、参考値としてお受け取りいただきたいですが、投資に見合うためのシステム導入をするためには、新たなビジネスチャンス（コスト削減ではなく、売上増加）を目指して生成AIを導入する必要がありそうです。

「残念ながら、生成AIには万能なソリューションはなく、コストは今までのシステム開発や導入に比べて不確実性が大きいです。」とRita Sallam氏は言います。「コストは、支出額、投資するユースケース、採用する導入アプローチによって決まります。市場を大きく変えるために生成AIをあらゆるところに導入したいと考えている場合や、生産性向上や既存プロセスの拡張に重点を置く堅実な場合など、費用、リスク、変動性、戦略的影響のレベルはそれぞれ異なります。」

生成AI導入に後ろ向きなことを書いてしまいましたが、導入の効果・成功例は多分にあります。Gartner社のレポートWhat Mature Organizations Do Differently for AI Successでは、ユース ケース、職種、従業員のスキル レベルに応じて異なるさまざまなビジネス改善を報告しています。最近の822名を対象とした調査では、回答者の平均では15.8%の収益増加、15.2%のコスト削減、22.6%の生産性向上が報告されており、使い所を適切に見極めることで、効果を得られることが分かっています。

次の章から生成AIプロジェクトの進め方を紹介します。

生成AI導入の進め方

1. 生成AIの得意不得意を知る

まず生成AIがどのようにビジネスに貢献できるかを理解することが大切です。生成AIとは、テキスト、画像、音声など、様々な形式のコンテンツを自動的に生成する技術です。下記に代表的な得意分野を記載します。

代表的な活用分野

• カスタマーサポートの自動化
• 商品説明やコンテンツの自動生成
• デザインや広告素材の生成
• 自動テキスト要約やレポート作成

2. プロジェクトの目的と目標を決める

まずビジネス課題を明確にするところから始まります。どのような問題を解決したいのか、あるいはどのプロセスを効率化したいのかを具体的に定義します。

• 目的の設定: 生成AIを導入することで達成したいゴールは何か？
• KPIの設定: 生成AIの効果を測るための指標（例：生成されたコンテンツの量、品質、時間の短縮など）を設定します。

3. データの収集と準備

自社のナレッジを学習させるためには、大量のデータが必要です。データの品質が精度に大きく影響します。以下のステップを踏んで、データの質を確保します。

• データの収集: 自社のデータや公開されているデータセットを活用します。
• データの前処理: データのクリーニングや正規化を行い、ノイズを除去します。
• データのアノテーション: 必要に応じて、データにラベル付けを行い、モデルが効果的に学習できるようにします。

4. モデル選定とカスタマイズ

生成AIモデルには、既存のオープンソースモデルやクラウドサービスで提供されているモデルを利用する方法があります。たとえば、OpenAIのGPTシリーズやDALL-Eなどの大規模言語モデルが有名です。

• 既存モデルの活用: 既存の生成AIモデルを使用すれば、導入がスムーズで費用対効果が高いです。
• カスタムモデルの構築: 自社のビジネスニーズに合わせてモデルをカスタマイズする場合、ファインチューニングが必要です。

5. インフラの選定と構築

生成AIは計算リソースを大量に使用するため、適切なインフラが必要です。クラウドサービス（AWS、GCP、Azureなど）を活用すると、スケーラビリティやコスト面で柔軟に対応できます。

• クラウドインフラの構築: 生成AIモデルのトレーニングや推論に最適化されたインフラを用意します。
• コストの最適化: 必要に応じてオンデマンドリソースを活用し、コストを管理します。

6. テストとパイロット運用

AIモデルの導入前には、十分なテストとパイロット運用を行う必要があります。生成AIの出力品質を確認し、ビジネス要件に合致しているかどうかを評価します。

• 生成結果の検証: 出力されたコンテンツが期待通りか、ユーザーが満足できる品質かを確認します。
• パイロット運用: 小規模なプロジェクトでまず運用を開始し、実際の運用に耐えられるかテストします。

7. 生成AIの運用と改善

生成AIは、導入した後も継続的な改善が可能です。運用中に得られたフィードバックをもとに、微調整を行います。

• パフォーマンスモニタリング: モデルの出力やパフォーマンスを監視し、問題があれば対応します。
• 継続的な改善: 新しいデータや技術を取り入れて、AIモデルを進化させ続けます。




まとめ

生成AIが「既存のデータを活用し、新たなコンテンツ（文章・画像・音声など）などまだ得られていないものを作る技術」であるため、その技術を作ることも正解のないプロジェクトです。

正解のない、つまり生成AIプロジェクトは場当たり的になってしまうのか？とご質問いただくことが多いのですが、それは違います。ここは他のシステム開発プロジェクトと同じで、適切な準備と計画が成功の鍵を握ります。目標を明確にし、データを整備し、生成AIを段階的に導入することで、途中で頓挫してしまう・システム構築したけれど使えない・想定より費用がかかる、などの失敗へのリスクを低減します。

当社では、生成AIの活用にむけて無料相談会を実施しています。みなさんが考えていることを具体化させる、次のタスク・ステップを明確にする、生成AIでできるか回答する、などのようなご相談も大歓迎です。ぜひお気軽にお問い合わせください。






X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse