FLINTERS の河内です。
週次で実施しているAIサービスの味見会。
今日は堀さんより Project as Code というプラクティスと、ローカルLLM Jan-v1 の話でした。
ドキュメントの継続的な更新と改善は手間がかかるため、最新状態を保つのはなかなか難しいのが実際のところではないかと思いますが、AIの発達により状況が変わってくるかもしれないという刺激的な内容でした。
本レポートは、週次AIサービスの味見会における発表や質疑応答の内容を、AIを活用してまとめたものです。これにより、議論のエッセンスを効率的に共有することを目指しました。
AIを活用したプロジェクトマネジメント
AIを活用したプロジェクトマネジメントについて、GitHub Projectsと「Project as Code」という考え方を用いた事例が紹介されました。これは、プロジェクトのドキュメントをコードとして管理し、AIに更新させるというアプローチです。GitHub Projectsを基盤とし、公開されているスケルトンテンプレートリポジトリを活用しています。
ドキュメント構成は、人間が情報を投入するinput_docsディレクトリと、AIが更新するproject_docsディレクトリに分かれています。AIには、input_docsの内容を読み取り、project_docsを更新するよう指示するルールが組み込まれています。
このアプローチの利点は、継続的なドキュメント更新の容易さです。人間はinput_docsに新しい情報や決定事項を投入するだけでよく、AIがproject_docsを自動的に更新します。これにより、これまで手が回らなかったドキュメント更新作業が効率化されます。また、エージェントがGitHubの公式MCPサーバーと連携し、リポジトリから過去1週間の進捗報告を自動で作成できるため、PMの負担軽減と報告の精度向上が期待されます。MCPツールを活用することで、タスク管理と実装状況を紐付けて管理できる点も魅力です。データを蓄積していくことで、AIモデルやAIツールセットの進化により、AIプロジェクト管理の精度がさらに向上する可能性を秘めています。
運用上の課題としては、メンバー全員が積極的にエージェントを活用するまでには至っておらず、チーム全体での意識向上が挙げられます。Slackなど日常的なチャットでの議論をGitHubに連携する意識付けも必要です。input_docsは単調増加するため、定期的な整理が必要になる可能性があります。project_docsは不変的なものではなく、常に更新されるドキュメントとして位置づけられており、プロジェクトに必要なリソース情報が常に最新の状態で維持されることを意味します。既存の進行中プロジェクトにも導入可能であり、GitHubを使っている場合はよりスムーズに始められるという見解も示されました。人間が作成したものをベースに、AIがドキュメントをブラッシュアップする点がDevinのDeep Wikiに似ているという意見も出ました。
ローカルLLMの活用事例
次に、ローカルLLMの活用事例として、Jan-v1モデルと検索ツール「serper.dev」を用いた実験について共有がありました。
ローカルLLMの環境構築には、LM StudioやOllamaなどのローカルLLMツール（モデルを動かす基盤となるソフトウェア）、オープンなLLMモデル、必要に応じてMCPツールが必要です。Jan-v1というモデルは非常に軽量（ダウンロードに5分程度）であることが強調され、GPT-3やDeepseek V3よりも賢いという評価もあるそうです。検索ツール「serper.dev」は2500クエリまで無料で、モデルにGoogle検索能力を持たせることができます。
試用結果では、LM Studioで「今週の主要なAIについて10項目まとめて」というプロンプトを試したところ、日本語で回答が生成されました。しかし、生成された内容には2024年のニュースが混じるなど、情報の古さや精度に課題が見られました。生成結果の精度が低いことから、Jan-v1、あるいは、検索APIが提供する結果の質が十分でない可能性が指摘されました。
手軽にローカルLLMが利用可能になっており、Google検索ツールをモデルに持たせられる点で利便性がある一方で、現状では精度に課題があることが示されました。
Discussion