microCMSブログ

microCMSの最新情報や活用事例などをお届けします。

エンジニアリング

microCMS社内開発勉強会の雰囲気(2025年12月編)

microCMS社内開発勉強会の雰囲気(2025年12月編)
りゅーそう りゅーそう

こんにちは。エンジニアのりゅーそうです。

microCMSのエンジニアチームでは、毎週1時間ほど社内勉強会をしています。

有志のメンバーが話題を持ち寄って発表したり、適当にテーマを設けて雑談したり、、、とゆるく数年間運営されています。

今回はそんなmicroCMSの勉強会ではどんなことが話されているのか?12月(全4回)で話した内容を紹介したいと思います。

第1週

OpenTofuとは

石井さんによるOpenTofuについての発表です。

microCMSではTerraformからOpenTofuへの移行を進めています。OpenTofuの作成された経緯から、そして今年CNCF(Cloud Native Computing Foundation)というクラウドネイティブコンピューティング技術を推進する非営利団体のプロジェクトになったという紹介がありました。

OpenTofuには

  • tfstateの暗号化
  • Terragruntとの相性の良さ(Automatic Provider Cache Dirの機能など)

などの機能面でのメリットに加え、

  • providerに for_each が使える
  • リソースを lifecycle で記述できる

など文法面でもスマートに書けるメリットがあるとのことでした。microCMSではインフラのアップデートも内部で続いております!

第2週

Amazon Bedrock周りについて

村松さんよりAmazon Bedrockについての解説です。

以前村松さんはMastraなどのAIエージェントのフレームワークについて解説をしていましたが、今回はプラットフォーム・インフラレイヤーについてAmazon Bedrockに着目しまとめてみたそうです。

Bedrockとはなに?という基礎から、Bedrockを使わずAIエージェント構築する場合と比べたメリットなどを解説していただきました。

技術選定のポイントとして、ファインチューニングを自前でやるか(=GPUが必要となるか?)と言う点をまず挙げていたのがわかりやすかったです。

その上でメリットとして、

  • VPCエンドポイントで閉域である
  • セキュリティがIAMなどと一体である
  • 運用コストが低い
  • 複数モデルを統一APIで叩ける
  • データ保護をAWS内で完結

などの点などを挙げていました。

「Bedrock Knowledge Bases」などのRAGのためのマネージド機能・Guardrailsによる入出力の制御など管理のしやすさ、後々チューニングしたい時に拡張しやすいと言う点が大きなメリットだそうです。

最後のまとめ

Mastra / LangChain のようなフレームワークは 「LLM をどう使うか」 の話

Bedrock は 「LLM をどう安全・安定的に動かすか」 の話

Bedrock Agents / AgentCore は 「エージェントをどう本番運用するか」 の話

と言う整理がAI機能を作る上で指針となりそうでとても参考になりました!

第3週

React2Shell「CVE-2025-55182」について

私から、先日話題となっていたReact Server Components周りで発生した脆弱性について話しました。

CVSS 10.0の重大な脆弱性であったこと、脆弱性が起きた技術的背景などを解説しました。個人的には今回の脆弱性でReact Flightとその仕組みについて詳しく知れました。

今回の脆弱性の内容などは事前にSlackでシェアや対策などされていたので、ここではなぜこの脆弱性が起きたのか?対策などを紹介しました。

hasOwnProperty をオブジェクト自身から直接呼び出してしまったことが原因で、その危険性やprototype 経由で呼び出す対応をReactチームがしたことを話しました。

JavaScriptでプログラミングを組む上での注意点などをチームに共有できて良かったと思います。

バックアップとは何か

北條さんより、バックアップという基礎からの話をしていただきました。

そもそもバックアップとは「データを別の場所・別の状態で保存し、障害やミスが起きても元に戻せる状態を作る」という定義の話から、なぜバックアップが必要なのか?という話がありました。

フル・差分・増分・永久増分バックアップの解説と違いやメリットデメリットを紹介していただきました。

その前提で、AWSでのAWS BackupやDynamoDBオンデマンドバックアップ、PITR(Point Time Recovery)についての解説がありました。

バックアップはRPO(どこまで古いデータを許容できるか)、RTO(復旧にどれくらい時間をかけられるか)の戦略を立てることが重要で、それに応じてPITRやオンデマンドバックアップのストレージクラスを検討すること必要があるそうです。

バックアップの戦略性・コスト最適化のバランスの難しさを感じれる発表でとても勉強になりました。

CSVインポート機能について

中島さんより、microCMSのCSVインポートについての解説です。

CSVインポート機能の対応フィールドの拡充を担当することが多かった経験からその設計や実装時に考慮するポイントなどをまとめてくださいました。

CSVインポート機能はAWS Step Functionsで非同期で実行されていること、そしてその内部処理がされているECSタスクの処理フローについて紹介がありました。

非同期の進捗のステータス(RUNNING、COMPLETE、ERRORの状態)とユーザーがCSVで入力したデータをどのようにmicroCMSのデータでフォーマット、バリデーションなどをしているかをまとめてくださいました。ヘッドレスCMSを作る上で、外部データをどうmicroCMS内に取り込むのかというのは大きなテーマとなります。今回の発表でその全体的なアーキテクチャが共有されて勉強になったと思います!

testing/synctestパッケージについて

寺田さんより、Go言語のsynctestパッケージについての解説です。

synctestは仮想環境(バブル)を作成し、これによって時間制御が可能になり並行処理のテストを可能としているそうです。

https://zenn.dev/aiiro/articles/e093a6baa8f697 の記事にある通り、Durably Blockedとは何なのか?ブロックされたままのゴルーチンがあるとpanic: deadlock: main bubble goroutine has exited but blocked goroutines remain [recovered, repanicked] エラーが起きることを実際のデモで紹介いただきました。

実際のユースケースとしては並行処理のテストはもちろん 、sleepをmockしているようなテストでは sync.testを使用することによってmockが不要になり並行でテストを実行できるので高速化のメリットがあるとのことです。

Goで並行処理をする際にはまた参照したいと思った発表で勉強になりました。

第4週

なぜLLMは質問に答えられるのか

村松さんより、LLMがどういう過程を経て、何をして回答を生成しているのか?という疑問について解説です!

結論LLMは「質問」に答えている訳ではなく、この文字列のあとに、どんな文字列が来やすいか?を確率的に計算しているだけだとのこと。学習データから統計的に次に来やすいトークンを計算し、パターンを抽出しているためChatGPTなどでは回答が「答えっぽく」なっているそうです。

その上で、そのトークンの確立分布を「狭める」ためにコンテキストが重要という話があり、とても参考になりました。

村松さん曰く、LLMをうまく使うコツは「賢い質問」をすることではなく「正しい続きを書かせる文脈(コンテキスト)を渡すこと」だとのことです!

GraphQL×Go言語の仕様と注意点

三由さんより、microCMSで利用しているGraphQLとGoを組み合わせた際のレスポンスの仕様をまとめた発表でした!

実際にGoの構造体で作成したエンドポイントをGraphQL経由で叩くと最終的な出力JSONはどのようになるのかを具体的にまとめてくださいました!

Goの言語仕様として

  • marshal・unmarshalをした際の挙動
  • omitemptyを指定した際の挙動
  • ゼロ値

などを考慮して最終的なレスポンスがどうなるのかを考慮する必要があります。

しかし例えばGoのomitemptyを指定すると、プロパティごと削除してJSON化されるが、GraphQLを経由すると最終的には null が出力されている例を紹介されていました。

microCMSでは non-null 制約がされていないレスポンスがあるため、Goの言語仕様と最終的なレスポンスが一致しないことがあります。その辺りの課題が明確になる良いまとめでした!

Renovate

宇都宮さんによるRenovateについての発表です!

GitHubが提供しているDependabotとの比較をしてくださいました!

Dependabotとの比較でいうとパッケージのグルーピング設定が優れており、設定の柔軟性という点ではRenovateにメリットがあるそうです。

例として、「devDependencyのminor/patchバージョンはオートマージ」するみたいな自動化もできるとのこと。

また細かい点として、レビュアーの設定などCODEOWNERSをDependabotは採用しなくてはいけないので、microCMS的にはそこがデメリットとしても挙げられていました。

その他にもDashboardなどのメリットもあり、microCMSではRenovateへの移行を検討しているところです!

まずは、無料で
試してみましょう。

microCMSは無料ではじめられます。
ご不明な点はお気軽にお問い合わせください。