『Claude Projectsと開発した話』というタイトルでClassmethod AI Talks(CATs) #2 に登壇しました
2024.09.28はじめに
クラスメソッド運営する、生成AIに関するコミュニティ「Classmethod AI Talks(CATs)」の第2回が9月25日に開催されました。
そこで、『Claude Projectsと開発した話』というタイトルで登壇しました。
登壇資料
『Claude Projectsと開発した話』
『Claude Projectsと開発した話』ということでリテールアプリ共創部の持田の方からお話させていただきます。よろしくお願いします。
今日のアジェンダ
今日のアジェンダです。
Claude Artifacts というのと、Claude Projectsという2つの機能に関してお話をするので、それぞれの機能概要をまずご説明します。
その後で今回のメインです、Claude Projectsを使った開発を少しやっていますので、その中で経験したことに関して細かいところも含めてご紹介できればと思っています。
その後、生成AIを活用して開発する部分であったりとか、Claudeを使って開発する際のTipsに関してご説明できればと思います。
それぞれの機能概要
まず、それぞれの機能概要に関してご説明していきます。
Claude Artifactsとは?
最初に、Claude Artifactsという機能があります。これは無料のユーザーでも使えます。
Claudeの画面で、Settings 画面の中に ”Enable artifacts” というラジオボタンがあり、それをオンにすると利用できます。
これは、チャットのClaudeに質問をした結果、例えばコードを生成しますとか、ドキュメントを出しますとか、画像を出しますという回答になった場合に、その生成されるもののコードとかドキュメント、画像などをArtifactsと呼んでいます。
その生成結果は、チャットのウィンドウとは別の領域にウィンドウの部分に表示されて管理されていくという形になっています。
例えばそれがコードの例であった場合には、簡単なシンタックスハイライトもありますので、見やすく表示されるようになっています。
生成されたArtifactsに関しては、クリップボードにコピーするボタン、ファイルとしてそのままダウンロードするボタン、他の人が参照できるように公開するURLを作る機能、後でご説明するClaude Projectsに Project Knowledgeとして追加するボタンなどがが表示されます。
同じチャットで、何回か同じファイルに関して作り直しをした場合には、Artifactsの中でファイルのバージョン管理が行われます。
チャットの結果、UIを生成するようなコードに例だった場合には、そのアーティファクトの中で「プレビュー」タブが出てきて、その結果を視覚的に確認することもできます。
ただこれはnpmパッケージが必要なUIだった場合には、エラーになってしまうので難しいこともありますが、簡単なものであれば、視覚的にその場で確認できる 機能になっています。
Artifactsのスクリーンショット
Artifactsのスクリーンショットです。
左側が普通のClaudeのチャット欄になっていて、この画像では、Reactのこういう画面を作りたいという内容でチャットをしています。
その結果、その回答として右側にArtifactsウィンドウが出てきています。
この画像の例では、Reactコードが出てきています。チャットと別のウィンドウで出てきています。
このArtifactsウィンドウの下の方に、Publish、ダウンロード、コピーをするボタンがそれぞれ並んでいるので、ここからコードを使っていけます。
Claude Projectsとは?
次にClaude Projectsをご説明します。
これはClaude ProやTeamプランのユーザーが利用可能な機能です。
Projectというものを作っていいきます。そのProjectの単位でProject Knowledgeという領域の部分に、テキストのスニペットやテキストファイルを追加することができます。
また、チャットの履歴も、Projectごとに、通常のものと分けて管理されるようになります。
Project Knowledgeに追加したテキストやテキストファイルは、そのProjectに紐づけたチャット時に毎回参照されるため、その質問のコンテキストとなるファイルを、毎回添付することが不要となり、その分手間が省けます。
また、先ほどArtifactsでご紹介した、コードをそのままProject Knowledgeに追加するボタンもありますので、これを使ってProject Knowledgeを増やしていくことも簡単にできます。
もう一つは、Project単位でcustom instructionsを追加できますので、例えば「あなたは優秀なプログラマーです」のようなロールであったり、どういうトーンで回答するのかといった指示を追加することができ、これも新しいチャットで毎回参照されます。
Claude Projectsのスクリーンショット
これは、Claude Projectsのスクリーンショットです。
これは「サンプルプロジェクト」というProjectを作った場合の例なんですが、左側が通常のClaudeのチャットで、右側にProject Knowledgeというカラムの入力欄が出てきています。
ここの、Add Contentというボタンを押しますと、テキストのスニペットかテキストファイルを追加するためのUIが出てきます。
その下の部分に、custom instructionsをセットするボタンがあるので、それを押すとダイアログが出てきて、instructionsの入力ができるUIになっています。
そのため、毎回Projectに切り替えてチャットを起こしていくUIになっています。
Claude Projectsを使った開発で経験したこと
ここからは、今回Claude Projectsを使った開発を経験しましたので、そこから得られたノウハウのお話しできればと思います。
Project Knowledgeに追加してよかったもの
Project Knowledgeという機能がありますが、そこにどういうテキストを追加していくのかというところが、毎回悩む部分かと思います。
今回、追加したものは、開発を始める前に追加した部分として、そのプロジェクトの背景となる知識や、関連する法律などをテキストファイルに書いて追加しました。
次に、どういうものを作ろうとしているのか、Webアプリケーションでとか、どういうプラットフォームを使ってといったシステムの概要を追加しました。
あとはシステムの方針として役割分担やシステム構成などもテキストに書いてみました。
今回のプロジェクトに固有の用語も、いくつか説明を追加しています。
データベースやストレージの設計方針などの当初考えていた内容をProject Knowledgeに追加しました。
これらは最初に追加した内容ですが、開発が進むに従って、例えば設計が固まってきたデータベースのスキーマであったり、ある程度実装できたAPIのソースコードなどもArtifactsを通じて追加していきました。
Project Knowledgeの効果を実感するとき
「よかったもの」の部分ですが、どういった点でよかったかと思ったかというと、例えば、まだ詳細な方針まで決まってない段階で一般的な技術的な質問を投げてみたときの回答が、Project Knowledgeに追加したコードの例やデータベースのスキーマを反映した例で説明されることがあったので、その時は役に立っているなと思いました。
また、例えばデータベースなどの方針がまだ固まってないときに、こういう情報を管理したいといった、かなり大雑把な、ふわっとした質問を投げても、今回の例にすごく近いな、役に立つなと思うようなデータベースのテーブル設計や、それを扱うAPIの実装例なんかを示してもらえたので、それも今回の用途にかなり非常に近いなと思いました。
これらはバックエンドですが、例えばUIのコンポーネントに何を使うのか、フレームワークはどうしていきたいという内容を設計方針に追加しておくと、画面設計に関する回答に、かなり反映されて織り込んだ形で回答されるので、その時も、よかったなと感じました。
開発で経験したこと
同じProjectでもチャット間ではコンテキストは共有されない
次に開発で経験した部分ですが、最初に驚いたのが、同じProjectでも、チャットをいくつか作る際にチャットの間ではコンテキストが共有されないことです。
あるチャットで発生した内容や検討したこと、コードの例などは新しいチャットでは共有されないので、そこは背景を説明する必要があります。
そこは、Project Knowledgeに追加すればいいのではと思われる部分もあるかもしれませんが、Claude Proにも使用制限、1日のチャットの量や5時間ごとにセットされる量などがありますので、Project Knowledgeにあまり多くの内容を追加すると、1回分の指示が長くなってしまいます。
その意味では、今回のチャットの分を確保しようとすると、Project Knowledgeの分は最低限にした方がいいのかなという考えています。
そういった点も勘案すると、ある部分に閉じたトラブルやデバッグの質問などは、1個のチャットに閉じてやらないといけないなか思いながら開発をすることになりました。
ただ、なかなかトラブルが解決しないとか、デバッグがうまくいかないという場合には、どうしても1個のチャットが長くなってしまいます。しかし、ある程度長くなってくると「あまり長いチャットは、制限に早く届くので、お勧めしません」というメッセージが出ます。
そのようなメッセージが出ることになるので、例えトラブルとかデバッグがうまくいかない場合でも、どこかのタイミングを自分で見極めて、新しいチャットにコンテキストを共有して移行したほうがいいなというタイミングの見極めが重要かと思いました。
Project Knowledgeでの重要な制約事項の伝え方に工夫が必要そう
Project Knowledgeという機能がありますが、そのProject Knowledgeに特に書式があるわけではないので、重要な制約事項だと思っている部分でも、伝え方に結構工夫がいるのかなと思うことがありました。
例えば、今回の開発だと Cloudflare D1 を採用しましたが、これはSQLiteなので、一般のデータベースにはない工夫がSQLに必要です。
Project Knowledgeの設計方針をまとめているところに「データベースはCloudflare D1を使う」と書いたつもりでしたが、何回かやり取りしてるとCloudflare D1では使えないSQLを提案されることがありました。そのチャットの中で、これはちょっと使えないので、Cloudflare D1を考慮した提案を、と依頼することがありました。
そのため、技術的な制約事項などをProject Knowledgeでどう表現していくのかという工夫が必要なのかなと思うことと、その前提が守られているのかという点は、依頼する側が都度確認する必要があるなと思っています。
生成AIとの開発に共通の事項
Artifacts の中身は、やはり確認が必要
生成AIとの開発に、おそらく共通するだろうなと思っていますが、チャットの結果、Artifactsに提示されるコードの中身はやはり確認が必要だなと思うことが何回かありました。
例えば、開発をしていて、Projectの中の同じチャットでいろいろやり取りをするなかで、直前のやり取りとも前提が違うコードの例が出てくることもありますし、依頼したものと違う箇所、意図したのと違う箇所が変わった例がArtifactsとして提示されることもありました。
また、そもそも Claudeが持っている知識が、ライブラリのバージョンが古いものだったりするので、そもそも組み方が違うケースもありますし、TypeScriptでという条件を明示しているが、型のエラーが出るようなこともありました。
そのため、もちろん必要に応じて内容を確認することや、意図を明確にして依頼する必要もあります。
もちろん、出てきたコードはレビューが必要だと思います。
さらに、依頼する場合に最新版のライブラリドキュメントを確認して、Claudeの知識とずれがある場合は、ドキュメントの例やコード例などを依頼に前提として添付してする必要があるのかなと思いました。
デバッグにハマって、都度 Claude に聞いていると、回答もループしてくる
今回の開発で、デバッグにはまってしまい、それを毎回Claudeに聞くという場面がありました。
具体的には、とある認証ライブラリのバグにハマってしまうことがあり、そのエラーメッセージやデバッグ方法を、毎回Claudeに聞くが、なかなか解決しないということがありました。
ただ、Artifactsの形式でコードが出てくると、次は解決するんじゃないかと期待して、中身を一生懸命確認するんですが、なかなか状況から抜けられないということがあり、明らかに回答がループしてるな、同じことを繰り返してるなということがありました。
そのため、同じチャットの中でずっと閉じていると、なかなか状況から抜けられないのですが、ただ、「もう今日は切り上げて、明日やります」という主旨のチャットをすると、「明日はこういう点を確認してください」という項目を提示してもらったのですが、その中に「ライブラリのバグもあるかもしれません」という視点を含めたちょっとマクロ視点の回答が出てきたので、やはり依頼する側が視点を変えて投げかけをするということも大事なのかなと思いました。
その他、Claudeと開発する際のTips
その他の部分です。
やはり、開発が進んでいくとProject Knowledgeの更新をサボりがちなのですが、マメに更新することが必要だなと思っています。
Artifactsをオンにすると、回答のたびに具体的なコードに落として回答してもらうことがありますが、コード生成が必要ではないフェーズ、例えば設計に関する相談に関しては「コードを生成せずに疑問点があれば質問してください」と書くと、要件定義っぽい進め方ができ、見通しがよくなることがありました。
そのため、Claudeと一緒に開発をする場合には、設計者・実装者としての自分と、プロジェクトマネジメントあるいは俯瞰した質問を、こちら側が意識して切り替えて、依頼の粒度を変えていくことを意識することが大事かなと思っています。
また、例えば大量のデータを扱う場合に、データ生成そのものをClaudeに依頼してしまうと使用制限に抵触してしまうので、直接データを作る依頼ではなく、データを扱うためのスクリプトを検討依頼するとスムーズに処理できるのかなと思います。
まとめ
まとめになります。
Claude Artifacts、Projectsを使うことである程度、開発はスムーズになるなという実感があります。
ただ、Claudeの得意な領域とか不得意な領域、また使用制限などを念頭において、どういう部分を依頼すると良くなるのかを意識して、適材適所で依頼していけば、良いパートナーとして開発効率を上げることができると思います。
そのため、依頼する側は開発を俯瞰したりミクロで見たりというスコープを意識して依頼するといいのかなと思います。
Claudeが上げてきた成果物の内容や、チャットの前後での矛盾、依頼した内容と回答の齟齬などの部分のコンテキストやクオリティの維持は、引き続き依頼者としての人間側がやる必要があるのかなと思っています。
以上で今回の発表を終わります。
ありがとうございました。
