Zenn
📖

Nookアプリの情報源強化：主要AI企業とクラウドプロバイダーの技術情報を自動収集する

2025/03/16に公開
AWS
Google Cloud
Azure
nook
tech

前回の記事「生成AIコンサルタントの情報収集を効率化！Nookアプリを導入した理由と実装解説」で紹介したNookアプリですが、さらに情報源を強化するためのカスタマイズを行いましたので、その内容を共有します。また、今回のデプロイ過程で遭遇したAWS CDKとTerraformの違いについても考察します。

1. 追加した情報源の概要

Nookの優れた点は、feed.tomlファイルを編集するだけで簡単に情報源をカスタマイズできることです。今回は以下の情報源を追加しました：

主要AI企業のフィード

  • Google Gemini Blog - Googleの最新のAIモデル「Gemini」に関する公式情報
  • Google AI Blog - GoogleのAI研究と開発に関する詳細な技術情報
  • Microsoft Research - Microsoftの研究部門からの最新AI研究

クラウドプロバイダーのAI関連フィード

  • AWS Machine Learning Blog - AWSの機械学習サービスに関する最新情報
  • AWS AI Blog - AWSのAI関連サービスとアップデート
  • Azure AI Blog - MicrosoftのAzure AI Servicesに関する情報
  • Azure AI Platform Blog - Azure AI Platformの最新アップデート
  • Google Cloud AI Blog - GCPのAI/ML関連サービスの最新情報

その他の有用なAI技術情報源

  • NVIDIA AI Blog - GPUの大手メーカーによるAI関連の技術情報
  • Hugging Face Blog - オープンソースAIコミュニティの最新情報

2. カスタマイズの背景と理由

このカスタマイズを行った主な理由は以下の通りです：

  1. クラウドプロバイダー間の比較を容易に：AWS、Azure、GCPは各社独自のAIサービスを提供しており、それぞれの進化を並行して追跡することで、クライアントに最適なソリューションを提案しやすくなります。

  2. 実装知識の拡充：各プラットフォームの実装例や新機能の情報が自動収集されるため、実装ノウハウが蓄積されます。特に、クラウドプロバイダーのブログには具体的な実装方法が詳しく解説されていることが多いです。

  3. 最新のAIモデル情報をワンストップで取得：Google Gemini、OpenAI GPT、Microsoft Copilotなど、主要なAIモデルの更新情報を一箇所で確認できるようになります。これにより、モデル間の比較や最適なモデル選定が容易になります。

  4. ハードウェア最適化の知見：NVIDIA AI Blogからは、AIモデルのハードウェア最適化に関する貴重な情報が得られます。大規模モデルの効率的な運用には、ハードウェアの知識も重要です。

3. 実装方法

Nookアプリのfeed.tomlファイルを編集して、新しい情報源を追加しました。以下が追加したコードです：

# クラウドプロバイダーのAI関連フィード
[[feeds]]
key = "aws_machine_learning"
name = "AWS Machine Learning Blog"
url = "https://aws.amazon.com/blogs/machine-learning/feed/"

[[feeds]]
key = "aws_ai_blog"
name = "AWS AI Blog"
url = "https://aws.amazon.com/blogs/ai/feed/"

[[feeds]]
key = "azure_ai_blog"
name = "Azure AI Blog"
url = "https://techcommunity.microsoft.com/t5/azure-ai-services-blog/rss-board/board-id/AzureAIBlog"

[[feeds]]
key = "azure_ai_platform"
name = "Azure AI Platform Blog"
url = "https://techcommunity.microsoft.com/t5/azure-ai-platform-blog/rss-board/board-id/AzureAIPlatformBlog"

[[feeds]]
key = "gcp_ai_blog"
name = "Google Cloud AI Blog"
url = "https://cloud.google.com/blog/products/ai-machine-learning/rss"

# その他の有用なAI技術情報源
[[feeds]]
key = "nvidia_ai_blog"
name = "NVIDIA AI Blog"
url = "https://blogs.nvidia.com/blog/category/deep-learning/feed/"

[[feeds]]
key = "ai_google_blog"
name = "Google AI Blog"
url = "https://ai.googleblog.com/feeds/posts/default"

4. デプロイプロセスと AWS CDK vs Terraform の考察

前回の記事では触れなかった部分ですが、Nookアプリのデプロイプロセスには重要なステップがあります。特にaws configureコマンドによる認証設定が必須です。

4.1 aws configureの重要性

aws configureコマンドは、AWSリソースにアクセスするための認証情報（アクセスキーID、シークレットアクセスキー、リージョンなど）を~/.aws/credentialsファイルに設定します。

aws configure
# AWS Access Key ID: [あなたのアクセスキー]
# AWS Secret Access Key: [あなたのシークレットキー]
# Default region name: [リージョン名、例：ap-northeast-1]
# Default output format: json

この設定がないと、make cdk-deployコマンドは失敗します。これは、CDKがAWSリソースにアクセスするために認証情報が必要だからです。

4.2 AWS CDK vs Terraform：初めての体験

以前の記事でTerraformを推奨していた私にとって、今回のNookアプリで使用されているAWS CDKは初めての体験でした。両者の違いを実感し、それぞれの長所と短所について考察してみました。

AWS CDKの特徴

  1. プログラミング言語による定義：TypeScript、Python、Java、C#などの一般的なプログラミング言語でインフラを定義できます。Nookでは、Pythonが使用されています。

  2. 動的なテンプレート生成：デプロイ時にCloudFormationテンプレートを動的に生成します。これにより、条件分岐やループなどのプログラミング構造を活用できます。

  3. AWS専用：AWSリソースに特化しており、AWSサービスとの統合が緊密です。

  4. 抽象化レベルが高い：高レベルの構成要素（Construct）を提供し、複雑なインフラを簡潔に記述できます。

Terraformの特徴

  1. 宣言的な構文：HashiCorp Configuration Language (HCL) という専用の宣言型言語を使用します。

  2. 事前定義されたインフラ：インフラの状態を事前に定義し、その状態に合わせてリソースを作成・更新します。

  3. マルチクラウド対応：AWS、Azure、GCP、その他多数のプロバイダーに対応しています。

  4. 状態管理：tfstateファイルでインフラの状態を追跡し、差分を検出します。

4.3 なぜNookはCDKを採用したのか？

Nookプロジェクトがなぜ私が推奨するTerraformではなくCDKを採用したのか、考察してみました：

  1. Pythonとの親和性：NookのアプリケーションコードはすべてPythonで書かれており、インフラコードも同じ言語で統一することでコードベースの一貫性を保っています。

  2. AWS専用のアーキテクチャ：NookはAWSのサービス（Lambda、S3、EventBridge）のみを使用しており、マルチクラウド対応の必要性がありません。

  3. 動的な設定：環境変数や設定ファイルに基づいてインフラを動的に構成する必要があり、プログラミング言語の柔軟性が活かせます。

  4. 開発者の経験：おそらく開発者がAWS CDKに精通していたか、AWSのエコシステム内で開発することを優先したのでしょう。

4.4 デプロイの内部動作

make cdk-deployコマンドを実行すると、以下のような処理が行われます：

  1. Makefileの実行: Makefileに定義されたcdk-deployターゲットが実行されます
  2. 共通ファイルのコピー: 共通の依存関係ファイルと共通のPythonモジュールがコピーされます
  3. CDKデプロイの実行: cdk deployコマンドが実行されます
  4. CloudFormationテンプレートの生成: CDKがPythonコードからCloudFormationテンプレートを生成します
  5. AWSリソースのデプロイ: 生成されたテンプレートを使用してAWSリソースがデプロイされます
  6. 一時ファイルの削除: コピーしたファイルが削除されます

4.5 CDKとTerraformの選択基準

今回の経験を通じて、CDKとTerraformの選択基準について以下のように考えるようになりました：

CDKが適している場合

  • 単一クラウド（AWS）に特化したプロジェクト
  • 既存のアプリケーションコードと同じ言語でインフラを定義したい場合
  • 複雑なロジックや条件分岐を含むインフラ定義が必要な場合
  • AWSサービスの最新機能をすぐに利用したい場合

Terraformが適している場合

  • マルチクラウド環境を管理する必要がある場合
  • クラウドに依存しない汎用的なスキルを身につけたい場合
  • 明示的な状態管理と差分検出が重要な場合
  • チーム内で統一された宣言的な構文を使いたい場合

5. カスタマイズ後の効果と今後の展望

このカスタマイズにより、Nookアプリは以下のような効果が期待できます：

  1. 情報源の多様化: 主要なAI企業とクラウドプロバイダーからの情報を一元的に収集
  2. クラウドサービス比較: AWS、Azure、GCPのAIサービスを並行して追跡し、比較検討が容易に
  3. 実装知識の拡充: 各プラットフォームの実装例や新機能の情報が自動収集され、実装ノウハウが蓄積

今後の展望としては、以下のような拡張が考えられます：

  1. Webスクレイピング機能の追加: RSSフィードが提供されていないサイト（例：Anthropicの公式ブログなど）からも情報を収集
  2. トピック分類機能: 特定のトピック（例：「RAG」「ファインチューニング」「マルチモーダル」など）に関する情報を自動的に分類・整理
  3. 重要度スコアリング: 情報の重要度を自動的に評価し、優先順位付け

まとめ

前回の記事で紹介したNookアプリですが、今回のカスタマイズでさらに情報源を強化しました。主要AI企業とクラウドプロバイダーの技術情報を自動収集できるようになったことで、AIコンサルタントとしての情報収集がさらに効率化され、クライアントへの価値提供が向上することが期待できます。

また、デプロイプロセスの詳細についても解説し、AWS CDKとTerraformの違いについて考察しました。私は以前の記事でTerraformを推奨していましたが、今回のNookプロジェクトでCDKを使用してみて、それぞれのツールに適した用途があることを実感しました。

マルチクラウド環境ではTerraformの汎用性が強みになりますが、AWS専用のプロジェクトではCDKの統合性と柔軟性が魅力的です。どちらのツールも素晴らしい選択肢であり、プロジェクトの要件や開発チームの経験に基づいて選択すべきでしょう。

AIの世界は日々進化しており、最新情報をキャッチアップし続けることは非常に重要です。Nookアプリがその一助となり、AIコンサルタントとしての活動をサポートできれば嬉しいです。

このカスタマイズが、同じようにNookアプリを活用している方々の参考になれば幸いです。また、さらなるカスタマイズや拡張のアイデアがあれば、ぜひ共有していきたいと思います。

最後に

私は2つのプラットフォームで生成AIに関する発信を行なっております。

生成AIサービスの考察を見たい方へ

生成AIサービスの動向やや具体的な内容は、noteで詳しく解説しています。

noteプロフィール: @mizupee

日々の生成AI分析を追いたい方へ

毎日1つの生成AIサービスを分析するTwitter投稿「#100DaysofAI」もぜひフォローください。簡潔なポイント分析とアイデア共有を継続中です。

Twitter: @mizupee

Discussion