[{"content":"agentic-para-kb という、Coding Agentが扱いやすいMarkdownナレッジベースのテンプレートを作りました。\nリポジトリはこちらです。 https://github.com/nkoguchi-dev/agentic-para-kb\nもともとのきっかけは、かなり厳しいセキュリティ要件に対応する業務が降ってきたことでした。\n正直、自分だけで普通に進めていたら、とても間に合わない量と期間でした。\nそこでCoding Agentをフル活用する前提で、要件、Word/Excelの資料、判断基準、作業状況、過去の決定をMarkdownに整理し、agentが毎回それを読んで作業できるようにしました。\nこれが思った以上にうまくいき、agentが単にコードを書くのではなく業務の前提情報を読んだうえで考えてくれるようになり、毎回ゼロから説明しなくても作業を進められるようになりました。\nただ、うまくいった仕組みも、自分の頭の中にあるだけでは再現できません。\n試行錯誤して作ったナレッジベースの構想を自分でも正しく反映できるようにするため、個別の業務情報や個人情報を取り除き、フレームワークとして抜き出して言語化することにしました。\nそうして作った汎用テンプレートが agentic-para-kb です。\n何を作った？ テンプレートとして残した中身はそれほど大げさではありません。\nPARAをベースにしたディレクトリ構造、agentが最初に読む AGENTS.md、各領域の入口になるMOC、未完タスクの集約、リンクチェック、アーカイブの扱いなどです。\n特に意識したのは、「地図」と「本文」を分けることです。\nAGENTS.md には常に読んでほしい薄い地図だけを置きます。\n詳しいルールや判断基準は別の場所に置き、必要になったときだけ読ませます。\nすべてを毎回読ませると重くなりますし、逆に地図がないとどこから読めばよいのか分かりません。このあたりの塩梅がかなり大事でした。\nまた、メール送信、デプロイ、公開状態の変更のような外向きの操作は人間が確認する前提にしました。\n外部へ影響する操作は、agentが勝手に完了させないようにしています。\nagentに任せる範囲を広げるほど、この境界をルールとして定義しないと大変なことになります。\nなぜナレッジベースだった？ 以前から、AIに渡す周辺情報の量と質で出力がかなり変わるとは感じていました。\n名詞や単語がかなり怪しい文字起こしでも、固有名詞や背景情報を先に集めておくとその後の議事録や要約の精度がかなり上がります。\n文脈が分かっているだけで、同じ音声やテキストからでも結果はかなり違います。\nこれは普段のChatGPTとの会話でも同じだと感じました。\nこちらの事情や前提、よく使う判断基準を渡しておくと、返ってくる答えは明らかに良くなります。\n逆に、毎回まっさらな状態から説明すると、同じような前提説明を何度も繰り返すことになります。\n業務でCoding Agentを本格的に使うには、この前提情報を毎回チャットに貼るだけでは足りません。\n要件や判断基準は増えていきますし、作業状況も変わります。\nそこで、Markdownで正本を持ち、ソースコードをCodexに読ませるように読み込ませればよいのではないかと考えました。\nただし、Markdownを無作為に増やしていくと、すぐに破綻することも見えていました。\nどれが今も有効な情報なのか、どれが古い記録なのか、現在のタスクはどこにあるのか、判断基準はどこにあるのか。\n人間なら雰囲気で読めても、agentにとっては構造がない情報の山になります。\nそこで、agentが読むことを前提にしたナレッジベースの構造が必要だと考えました。Markdownであれば何でもよい、というわけではなかったですね。\nなぜPARAだった？ 最初は、ソースコードのようにレイヤーで情報を管理できないかと考えていました。\n普段扱っているコードでは、ドメインの中心と外側の実装を分ける設計に慣れています。\n同じように、個人のメモや判断基準も構造で分けられると、agentに説明しやすくなるはずです。\nそこで、ドキュメントやメモを構造化するためのフレームワークを探し、PARAを土台にすることにしました。\nProjects、Areas、Resources、Archivesという分類は分かりやすく、特にProjectとAreaを分ける考え方が便利でした。\n「いつ終わったと言えるか」があるものはProject、継続的に維持する責任はArea、という分け方はagentにも説明しやすいですね。\nもう一つ気に入ったのが、ProjectやAreaを終えたあとに、再利用できる知識を蒸留してからArchiveするという考え方です。\n終わったものをただ捨てるのではなく、今後も使えるルールや知識だけを残す。\nこれは、agentが古い情報を現在の根拠として拾ってしまう問題への対策にもなります。\nただ、PARAだけで十分だったわけではありません。\n自分の用途では、構造ルールや判断基準のようにあまり動かしたくない情報を置く場所が必要でした。\nそこで _core を追加しました。\nまた、いつ・なぜその選択をしたのかを残すために decisions も追加しました。\nPARAをそのまま使うというより、agentが扱いやすいように少し拡張した形ですね。\n追加して効いたもの まず効いているのはMOCです。\n各ProjectやAreaに入口となるMOCを置き、そこにステータスや次のアクションを集めるようにしました。\nファイルやディレクトリに番号を付けておくことで、agentが対象を見つけやすくなります。\n人間向けの見栄えというより、agentが迷わず辿れることを優先しています。このあたりはかなり割り切りました。\n次に、タスクの扱いです。\nタスクは各ProjectやAreaのMOCに置き、それを横断ビューとして集約します。\nこれにより、作業開始時に未完タスクを一覧しつつ、詳しい文脈は元のMOCへ戻って確認できます。\n会議メモの扱いも重要でした。\n会議の文字起こしや議事録は、あくまで入力記録です。\nその場で出たアクションや決定をすぐに各ProjectやAreaへ反映したくなりますが、議事録作成中のセッションでは反映先の文脈が薄いことがあります。\nそこで、複数領域にまたがる決定が出た場合は、まず「関連するProjectやAreaを読んだうえで反映する」というTODOを作るようにしました。\nこれにより、文脈の浅い状態で間違ったタスクを作る事故を減らせます。地味ですがかなり効いています。\nさらに、メッセージやメールなどの情報も必要に応じて読み込めるようにすると、返信文や議事録のドラフト精度がかなり上がります。\nagentは文章を書くのが得意ですが、周辺情報がないと一般論になりがちです。\n逆に、文脈が揃っていると、かなり実用的な下書きを作れるようになります。\n運用を始めてみて 運用を始めてみると、狙いはかなり合っていたと感じています。\n毎回ゼロから説明しなくても、agentがMOCや関連メモを読んで作業を始められるようになりました。\n開発タスクの作成、メール返信、議事録作成のような作業では、周辺情報が蓄積されている効果が分かりやすく出ます。\n一番効果が大きかったのは、業務での開発タスク作成です。\nドメインオーナーとの打ち合わせ内容、そこで決まったこと、機能を作る背景、既存コードの状態をagentがまとめて読んだうえで、「なぜこの変更を行うのか」を理解してくれます。\nそのうえで、コードの変更が必要な箇所を把握し、JiraのチケットをMCP経由で作成できるようになりました。\n単に議事録からTODOを抜き出すのではなく、背景とコードの両方を見たうえでタスクに落とせるのが大きいですね。\nもう一つ大きいのは、メールのドラフト作成です。\n大手企業の担当者にメールする場合でも、社内での決定、利用者向けの確認結果やアンケートの結果、アプリケーションの現在の状態などを踏まえて下書きを作ってくれます。\nそのため、以前より手直しがかなり少なくなりました。\n文章を書く能力だけでなく、前提情報を正しく持っていることが効いているのだと思います。\n一方で、問題もあります。\n情報量が増えるほど重くなります。\n読むファイルが多ければ遅くなりますし、Tokenの利用量も増えます。\n何でも読ませればよいという話ではなく、どこまでを常時読む地図にして、どこからを必要なときだけ読む本文にするかは、まだ調整が必要です。このあたりは少し悩ましいですね。\nその意味では、agentic-para-kb は完成品というより、agent時代の知識管理を試すための最初の型です。\nMarkdownで情報を持つだけなら簡単ですが、agentが扱える形で育てていくには、構造と運用ルールが要ります。\nしばらく使いながら、ちょうどよい重さと粒度を探していきたいと考えています。\n","permalink":"https://nkoguchi-dev.github.io/blog/posts/agentic-para-kb/","summary":"\u003cp\u003e\u003ccode\u003eagentic-para-kb\u003c/code\u003e という、Coding Agentが扱いやすいMarkdownナレッジベースのテンプレートを作りました。\u003cbr\u003e\nリポジトリはこちらです。 \u003ca href=\"https://github.com/nkoguchi-dev/agentic-para-kb\"\u003ehttps://github.com/nkoguchi-dev/agentic-para-kb\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eもともとのきっかけは、かなり厳しいセキュリティ要件に対応する業務が降ってきたことでした。\u003cbr\u003e\n正直、自分だけで普通に進めていたら、とても間に合わない量と期間でした。\u003cbr\u003e\nそこでCoding Agentをフル活用する前提で、要件、Word/Excelの資料、判断基準、作業状況、過去の決定をMarkdownに整理し、agentが毎回それを読んで作業できるようにしました。\u003c/p\u003e\n\u003cp\u003eこれが思った以上にうまくいき、agentが単にコードを書くのではなく業務の前提情報を読んだうえで考えてくれるようになり、毎回ゼロから説明しなくても作業を進められるようになりました。\u003c/p\u003e\n\u003cp\u003eただ、うまくいった仕組みも、自分の頭の中にあるだけでは再現できません。\u003cbr\u003e\n試行錯誤して作ったナレッジベースの構想を自分でも正しく反映できるようにするため、個別の業務情報や個人情報を取り除き、フレームワークとして抜き出して言語化することにしました。\u003cbr\u003e\nそうして作った汎用テンプレートが \u003ccode\u003eagentic-para-kb\u003c/code\u003e です。\u003c/p\u003e\n\u003ch2 id=\"何を作った\"\u003e何を作った？\u003c/h2\u003e\n\u003cp\u003eテンプレートとして残した中身はそれほど大げさではありません。\u003cbr\u003e\nPARAをベースにしたディレクトリ構造、agentが最初に読む \u003ccode\u003eAGENTS.md\u003c/code\u003e、各領域の入口になるMOC、未完タスクの集約、リンクチェック、アーカイブの扱いなどです。\u003c/p\u003e\n\u003cp\u003e特に意識したのは、「地図」と「本文」を分けることです。\u003cbr\u003e\n\u003ccode\u003eAGENTS.md\u003c/code\u003e には常に読んでほしい薄い地図だけを置きます。\u003cbr\u003e\n詳しいルールや判断基準は別の場所に置き、必要になったときだけ読ませます。\u003cbr\u003e\nすべてを毎回読ませると重くなりますし、逆に地図がないとどこから読めばよいのか分かりません。このあたりの塩梅がかなり大事でした。\u003c/p\u003e\n\u003cp\u003eまた、メール送信、デプロイ、公開状態の変更のような外向きの操作は人間が確認する前提にしました。\u003cbr\u003e\n外部へ影響する操作は、agentが勝手に完了させないようにしています。\u003cbr\u003e\nagentに任せる範囲を広げるほど、この境界をルールとして定義しないと大変なことになります。\u003c/p\u003e\n\u003ch2 id=\"なぜナレッジベースだった\"\u003eなぜナレッジベースだった？\u003c/h2\u003e\n\u003cp\u003e以前から、AIに渡す周辺情報の量と質で出力がかなり変わるとは感じていました。\u003cbr\u003e\n名詞や単語がかなり怪しい文字起こしでも、固有名詞や背景情報を先に集めておくとその後の議事録や要約の精度がかなり上がります。\u003cbr\u003e\n文脈が分かっているだけで、同じ音声やテキストからでも結果はかなり違います。\u003c/p\u003e\n\u003cp\u003eこれは普段のChatGPTとの会話でも同じだと感じました。\u003cbr\u003e\nこちらの事情や前提、よく使う判断基準を渡しておくと、返ってくる答えは明らかに良くなります。\u003cbr\u003e\n逆に、毎回まっさらな状態から説明すると、同じような前提説明を何度も繰り返すことになります。\u003c/p\u003e\n\u003cp\u003e業務でCoding Agentを本格的に使うには、この前提情報を毎回チャットに貼るだけでは足りません。\u003cbr\u003e\n要件や判断基準は増えていきますし、作業状況も変わります。\u003cbr\u003e\nそこで、Markdownで正本を持ち、ソースコードをCodexに読ませるように読み込ませればよいのではないかと考えました。\u003c/p\u003e\n\u003cp\u003eただし、Markdownを無作為に増やしていくと、すぐに破綻することも見えていました。\u003cbr\u003e\nどれが今も有効な情報なのか、どれが古い記録なのか、現在のタスクはどこにあるのか、判断基準はどこにあるのか。\u003cbr\u003e\n人間なら雰囲気で読めても、agentにとっては構造がない情報の山になります。\u003c/p\u003e\n\u003cp\u003eそこで、agentが読むことを前提にしたナレッジベースの構造が必要だと考えました。Markdownであれば何でもよい、というわけではなかったですね。\u003c/p\u003e\n\u003ch2 id=\"なぜparaだった\"\u003eなぜPARAだった？\u003c/h2\u003e\n\u003cp\u003e最初は、ソースコードのようにレイヤーで情報を管理できないかと考えていました。\u003cbr\u003e\n普段扱っているコードでは、ドメインの中心と外側の実装を分ける設計に慣れています。\u003cbr\u003e\n同じように、個人のメモや判断基準も構造で分けられると、agentに説明しやすくなるはずです。\u003c/p\u003e\n\u003cp\u003eそこで、ドキュメントやメモを構造化するためのフレームワークを探し、PARAを土台にすることにしました。\u003cbr\u003e\nProjects、Areas、Resources、Archivesという分類は分かりやすく、特にProjectとAreaを分ける考え方が便利でした。\u003cbr\u003e\n「いつ終わったと言えるか」があるものはProject、継続的に維持する責任はArea、という分け方はagentにも説明しやすいですね。\u003c/p\u003e\n\u003cp\u003eもう一つ気に入ったのが、ProjectやAreaを終えたあとに、再利用できる知識を蒸留してからArchiveするという考え方です。\u003cbr\u003e\n終わったものをただ捨てるのではなく、今後も使えるルールや知識だけを残す。\u003cbr\u003e\nこれは、agentが古い情報を現在の根拠として拾ってしまう問題への対策にもなります。\u003c/p\u003e\n\u003cp\u003eただ、PARAだけで十分だったわけではありません。\u003cbr\u003e\n自分の用途では、構造ルールや判断基準のようにあまり動かしたくない情報を置く場所が必要でした。\u003cbr\u003e\nそこで \u003ccode\u003e_core\u003c/code\u003e を追加しました。\u003cbr\u003e\nまた、いつ・なぜその選択をしたのかを残すために \u003ccode\u003edecisions\u003c/code\u003e も追加しました。\u003cbr\u003e\nPARAをそのまま使うというより、agentが扱いやすいように少し拡張した形ですね。\u003c/p\u003e\n\u003ch2 id=\"追加して効いたもの\"\u003e追加して効いたもの\u003c/h2\u003e\n\u003cp\u003eまず効いているのはMOCです。\u003cbr\u003e\n各ProjectやAreaに入口となるMOCを置き、そこにステータスや次のアクションを集めるようにしました。\u003cbr\u003e\nファイルやディレクトリに番号を付けておくことで、agentが対象を見つけやすくなります。\u003cbr\u003e\n人間向けの見栄えというより、agentが迷わず辿れることを優先しています。このあたりはかなり割り切りました。\u003c/p\u003e\n\u003cp\u003e次に、タスクの扱いです。\u003cbr\u003e\nタスクは各ProjectやAreaのMOCに置き、それを横断ビューとして集約します。\u003cbr\u003e\nこれにより、作業開始時に未完タスクを一覧しつつ、詳しい文脈は元のMOCへ戻って確認できます。\u003c/p\u003e\n\u003cp\u003e会議メモの扱いも重要でした。\u003cbr\u003e\n会議の文字起こしや議事録は、あくまで入力記録です。\u003cbr\u003e\nその場で出たアクションや決定をすぐに各ProjectやAreaへ反映したくなりますが、議事録作成中のセッションでは反映先の文脈が薄いことがあります。\u003cbr\u003e\nそこで、複数領域にまたがる決定が出た場合は、まず「関連するProjectやAreaを読んだうえで反映する」というTODOを作るようにしました。\u003cbr\u003e\nこれにより、文脈の浅い状態で間違ったタスクを作る事故を減らせます。地味ですがかなり効いています。\u003c/p\u003e","title":"agentic-para-kbを作った"},{"content":"気象庁が観測している気温データをヒートマップで表示するだけのアプリを作ってみました。\nhttps://heat-chronicle.koppepan.org\nリポジトリはこちらです。 https://github.com/nkoguchi-dev/heat-chronicle\nせっかくAWSで公開するところまできちんとやったのでメモを残しておきます。\nなぜ作った？ 過去に何かのニュースで過去100年のデータをヒートマップで表したという画像を見た記憶があり、自分の住んでいるところのデータも見てみたいと考えたのがきっかけでした。要するに模倣ですね。\nまた昨今のAIコーディングが非常に優れているために「有名サービスの自分専用カスタマイズ」のようなアプリケーションを作成して自分だけが楽しんで利用する、ということができるようになりました。Claude Coworkの発表が引き金となってIT企業の株価が暴落した、といったニュースが流れていたので実力を試してみたくなったというのが動機です。\nどうやって作った？ 作り方は現在では一般的と思われる方法で、Claude Coworkを使って仕様を詰めてClaude Codeで実装する形です。Coworkはまだ制限が多くファイルの削除ができないなどコーディングするには向いていない制約があったのでコード全体を把握したCoworkと一緒に設計を考えながら設計書を出力、Claude Codeで実装をする形にしました。感覚としては以前あったClaude Codeのプランモードでプラン部分だけOpusを使う形に近いです。\n実装は全てお任せで自分では1行もコードを書いておらず、コードのチェックもコミット前におかしな箇所がないか軽く確認した程度です。そのためコード全体をきちんと確認すると改善すべき箇所は多くあると思いますが、自分で決めた大まかなコーディング規約が守られていれば細かい点は気にしなくてもよいのではないかと考えています。\n実装から公開までにかかった時間はデータを表示するまで3時間程度、そこからAWSで動作できるまで1日、諸々の調整に半日ほどでした。AWSのリソース作成はTerraformで行ったため、こちらもClaude Cowork/Codeを利用して作っています。\n振り返りと今後に向けて 技術選定 フロントエンド: Next.js（SPA）\nバックエンド: Python + FastAPI\nデータベース: DynamoDB\nAWSで動作させるためのランニングコストを限りなく低く抑えるためにLambda + DynamoDBで動作させるようにしています。\nDynamoDBは初めてだったので少し学習する必要がありました。ほんの少しだけですが。\n最初の設計と実際のズレ ローカルでしか動かすつもりはなかったので細かいことは考えていなかったのですが、3時間程度とあまりに早くアプリケーションが動いてしまったので欲が出てAWSで稼働させるためにデータベースをDynamoDBに変更しています。\n最初からDynamoDBを想定していればもっと早く作れたかもしれません。早すぎて恐ろしいですね。\n上手くいった点 Claude Coworkができること／できないことを把握することができました。プログラムだけならClaude Codeだけで良いのでは？と考えていましたが、仕様を練る部分ではOpus4.6を利用したCoworkが相手の方が良いようです。Claude Codeとできることに差がなさそうですが何か違いがあるのでしょうか？\nまたEC2やECSではなくLambdaでバックエンドを動作させるという経験ができたのが大きいですね。\nPythonだと遅いのではないか、Rustで作る必要があるのではないかと考えながら実装を進めましたが動かしてみるとPythonでもあまり気にならない速度でした。コールドスタートは気持ち待たされますがこの程度なら許容範囲内ですね。目新しさや使ってみたい感からRustが選択肢に上がってしまうことが多いのですが、大半はPythonで何とかなる＋何も問題がないという事も分かっているのでPythonで済ませることができたのは良かった点だと考えています。\n次は改善したい点 DynamoDBは名前くらいしか知らない状態で把握できていなかったので、概要と簡単な利用方法くらいは把握しておけば良かったかなと少し後悔がありました。\nその他は技術選定・実装期間・ランニングコストと及第点だったと考えています。\n構成 フロントエンド: Next.js 16 / React 19 / TypeScript / Tailwind CSS v4 バックエンド: Python 3.12 / FastAPI データベース: Amazon DynamoDB（ローカル開発は DynamoDB Local） インフラ: AWS Lambda + API Gateway / S3 + CloudFront / Terraform CI/CD: GitHub Actions / AWS ECR ","permalink":"https://nkoguchi-dev.github.io/blog/posts/heat-chronicle/","summary":"\u003cp\u003e気象庁が観測している気温データをヒートマップで表示するだけのアプリを作ってみました。\u003cbr\u003e\n\u003ca href=\"https://heat-chronicle.koppepan.org\"\u003ehttps://heat-chronicle.koppepan.org\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eリポジトリはこちらです。 \u003ca href=\"https://github.com/nkoguchi-dev/heat-chronicle\"\u003ehttps://github.com/nkoguchi-dev/heat-chronicle\u003c/a\u003e\u003cbr\u003e\nせっかくAWSで公開するところまできちんとやったのでメモを残しておきます。\u003c/p\u003e\n\u003ch2 id=\"なぜ作った\"\u003eなぜ作った？\u003c/h2\u003e\n\u003cp\u003e過去に何かのニュースで過去100年のデータをヒートマップで表したという画像を見た記憶があり、自分の住んでいるところのデータも見てみたいと考えたのがきっかけでした。要するに模倣ですね。\u003c/p\u003e\n\u003cp\u003eまた昨今のAIコーディングが非常に優れているために「有名サービスの自分専用カスタマイズ」のようなアプリケーションを作成して自分だけが楽しんで利用する、ということができるようになりました。Claude Coworkの発表が引き金となってIT企業の株価が暴落した、といったニュースが流れていたので実力を試してみたくなったというのが動機です。\u003c/p\u003e\n\u003ch2 id=\"どうやって作った\"\u003eどうやって作った？\u003c/h2\u003e\n\u003cp\u003e作り方は現在では一般的と思われる方法で、Claude Coworkを使って仕様を詰めてClaude Codeで実装する形です。Coworkはまだ制限が多くファイルの削除ができないなどコーディングするには向いていない制約があったのでコード全体を把握したCoworkと一緒に設計を考えながら設計書を出力、Claude Codeで実装をする形にしました。感覚としては以前あったClaude Codeのプランモードでプラン部分だけOpusを使う形に近いです。\u003c/p\u003e\n\u003cp\u003e実装は全てお任せで自分では1行もコードを書いておらず、コードのチェックもコミット前におかしな箇所がないか軽く確認した程度です。そのためコード全体をきちんと確認すると改善すべき箇所は多くあると思いますが、自分で決めた大まかなコーディング規約が守られていれば細かい点は気にしなくてもよいのではないかと考えています。\u003c/p\u003e\n\u003cp\u003e実装から公開までにかかった時間はデータを表示するまで3時間程度、そこからAWSで動作できるまで1日、諸々の調整に半日ほどでした。AWSのリソース作成はTerraformで行ったため、こちらもClaude Cowork/Codeを利用して作っています。\u003c/p\u003e\n\u003ch2 id=\"振り返りと今後に向けて\"\u003e振り返りと今後に向けて\u003c/h2\u003e\n\u003ch3 id=\"技術選定\"\u003e技術選定\u003c/h3\u003e\n\u003cp\u003eフロントエンド: Next.js（SPA）\u003cbr\u003e\nバックエンド: Python + FastAPI\u003cbr\u003e\nデータベース: DynamoDB\u003cbr\u003e\nAWSで動作させるためのランニングコストを限りなく低く抑えるためにLambda + DynamoDBで動作させるようにしています。\u003cbr\u003e\nDynamoDBは初めてだったので少し学習する必要がありました。ほんの少しだけですが。\u003c/p\u003e\n\u003ch3 id=\"最初の設計と実際のズレ\"\u003e最初の設計と実際のズレ\u003c/h3\u003e\n\u003cp\u003eローカルでしか動かすつもりはなかったので細かいことは考えていなかったのですが、3時間程度とあまりに早くアプリケーションが動いてしまったので欲が出てAWSで稼働させるためにデータベースをDynamoDBに変更しています。\u003cbr\u003e\n最初からDynamoDBを想定していればもっと早く作れたかもしれません。早すぎて恐ろしいですね。\u003c/p\u003e\n\u003ch3 id=\"上手くいった点\"\u003e上手くいった点\u003c/h3\u003e\n\u003cp\u003eClaude Coworkができること／できないことを把握することができました。プログラムだけならClaude Codeだけで良いのでは？と考えていましたが、仕様を練る部分ではOpus4.6を利用したCoworkが相手の方が良いようです。Claude Codeとできることに差がなさそうですが何か違いがあるのでしょうか？\u003cbr\u003e\nまたEC2やECSではなくLambdaでバックエンドを動作させるという経験ができたのが大きいですね。\u003cbr\u003e\nPythonだと遅いのではないか、Rustで作る必要があるのではないかと考えながら実装を進めましたが動かしてみるとPythonでもあまり気にならない速度でした。コールドスタートは気持ち待たされますがこの程度なら許容範囲内ですね。目新しさや使ってみたい感からRustが選択肢に上がってしまうことが多いのですが、大半はPythonで何とかなる＋何も問題がないという事も分かっているのでPythonで済ませることができたのは良かった点だと考えています。\u003c/p\u003e\n\u003ch3 id=\"次は改善したい点\"\u003e次は改善したい点\u003c/h3\u003e\n\u003cp\u003eDynamoDBは名前くらいしか知らない状態で把握できていなかったので、概要と簡単な利用方法くらいは把握しておけば良かったかなと少し後悔がありました。\u003cbr\u003e\nその他は技術選定・実装期間・ランニングコストと及第点だったと考えています。\u003c/p\u003e\n\u003ch2 id=\"構成\"\u003e構成\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eフロントエンド: Next.js 16 / React 19 / TypeScript / Tailwind CSS v4\u003c/li\u003e\n\u003cli\u003eバックエンド: Python 3.12 / FastAPI\u003c/li\u003e\n\u003cli\u003eデータベース: Amazon DynamoDB（ローカル開発は DynamoDB Local）\u003c/li\u003e\n\u003cli\u003eインフラ: AWS Lambda + API Gateway / S3 + CloudFront / Terraform\u003c/li\u003e\n\u003cli\u003eCI/CD: GitHub Actions / AWS ECR\u003c/li\u003e\n\u003c/ul\u003e","title":"最高気温のヒートマップ"}]