金曜日, 12月 19, 2025
No menu items!
ホーム ブログ ページ 3201

「FFVIIエバークライシス、忘れられぬ物語登場!」

スクウェア・エニックスは2025年7月15日、『FINAL FANTASY VII EVER CRISIS(ファイナルファンタジーVII エバークライシス)』の新チャプターを発表しました。7月17日より、CHAPTER9「暴かれる真実」が配信され、原作『ファイナルファンタジーVII』の重要な地点である忘らるる都が描かれる予定です。対応プラットフォームはPC(Steam)、iOS、Androidです。

## ゲームの概要

『FF7EC』は、スクウェア・エニックスとアプリボットが共同開発した基本プレイ無料の運営型ゲームです。プレイヤーは『ファイナルファンタジーVII』シリーズのキャラクターを編成し、ATB制のコマンドバトルを通じて進行します。フィールド上では、デフォルメデザインでキャラクターたちが描かれ、原作の物語や世界観が忠実に再現されています。

現在、ゲームは『ファイナルファンタジーVII』と『クライシス コア -ファイナルファンタジーVII-』の物語を基に、さまざまなチャプターが更新中です。また、原作にないエピソードである『ファイナルファンタジー VII ザ ファーストソルジャー』も完結しており、セフィロスの過去のエピソードが展開されています。

## CHAPTER9の詳細

新たに配信されるCHAPTER9では、古代種の神殿や忘らるる都にまつわる物語が展開される模様です。『FF7EC』は『ファイナルファンタジーVIIリメイク』と異なり、原作により忠実なストーリーを提供することが特徴であり、感動的なシーンの再現が期待されます。

原作では、忘らるる都は物語の重要なターニングポイントであり、今後の展開に期待が高まります。これにより、同じ舞台を扱った他の作品『ファイナルファンタジーVIIリバース』との比較も楽しめるかもしれません。

## 現在のイベントとガチャ

ゲーム内では、エアリスやティファ、ユフィの「水着」ウェア、さらにはアンジールの「リゾートスタイル」ウェアが入手できるガチャが開催中です。また、期間限定のイベント「海賊王の挑戦状」と「渚のユフィ出撃」も行われており、CHAPTER9のリリースに合わせたプレイが推奨されています。

## まとめ

『FINAL FANTASY VII EVER CRISIS』は、現在無料で配信中です。原作ファンにとっては見逃せないコンテンツが多く、特に新チャプターの配信は大きな注目を集めています。ゲームはiOS、Android、PC(Steam)で体験可能です。リリースから約2年の時を経て、さらに魅力的な物語が展開されることが期待されます。

🧠 編集部より:

補足説明

スクウェア・エニックスが開発した『FINAL FANTASY VII EVER CRISIS』(FF7EC)は、シリーズのファンにとって待望の無料運営型ゲームです。7月17日より配信されるCHAPTER9「暴かれる真実」では、原作『ファイナルファンタジーVII』に出てくる「忘らるる都」が描かれ、物語が大きく展開します。

ゲームの特徴

本作は、基本プレイが無料であるため、気軽にプレイを始められます。ATB(Active Time Battle)制のコマンドバトルを採用しており、オリジナルキャラクターを編成し、自分だけのパーティを作成できるのが魅力です。また、デフォルメデザインによって、ビジュアルも親しみやすいものとなっています。プレイヤーは、原作に忠実なストーリーやキャラクターたちとの交流を楽しむことができます。

CHAPTER9の内容

CHAPTER9「暴かれる真実」では、特に重要なストーリーの一部が描かれ、原作の感動的なシーンが再現されると期待されています。このチャプターは物語のターニングポイントともなるため、長い間待ち望まれていたファンにとっては特に注目のイベントです。同じく物語を描く『ファイナルファンタジーVIIリバース』とも比較することで、異なる展開を楽しむことができます。

ブランディングと背景

FF7ECは、シリーズの魅力を新たな形で伝える作品として位置づけられています。リメイクが進む中で、原作に対する敬意を表した「原作に忠実な物語」としても評価されるこのゲームは、ファンにとって重要な資産です。

豆知識

  • 忘らるる都: オリジナル版では物語のキーポイントとして知られ、多くのキャラクターの過去や未来に関わる重要な場所です。
  • ATB制: 『ファイナルファンタジー VII』の人気システムであり、戦闘においてリアルタイムとターン制の要素を組み合わせるユニークな方法です。

関連リンク

新チャプターとゲーム内イベントを楽しむことで、FF7の世界に再度浸るチャンスです。気になる方は、ぜひチェックしてみてください!

  • キーワード: エバークライシス

FINAL FANTASY VII EVER CRISIS をAmazonで探す

エアリス・ティファ・ユフィ 水着 ウェア をAmazonで探す

アンジール リゾートスタイル ウェア をAmazonで探す



※以下、出典元
▶ 元記事を読む

Views: 0

『ズートピア2』12月5日公開!ジュディ&ニックの再会に期待高まる!

『ズートピア2』の日本公開日が2025年12月5日(金)に正式に決定しました。この続編は、前作『ズートピア』の成功を受けて制作され、再び多くのキャラクターたちが登場します。

特に注目すべきは、本作のストーリーの中心となるのが「指名手配犯のヘビ」であることです。この設定は、緊張感やユーモアを兼ね備えた新たな冒険を予感させます。前作同様、社会問題にも触れたメッセージを持つ作品になると期待されており、多くのファンがその展開を楽しみにしています。

公開日が近づくにつれ、さらに多くの情報が明らかになることでしょう。ファンの皆さんは準備を整え、この再びのズートピアの冒険を楽しみにしましょう!

ズートピア2

🧠 編集部より:

『ズートピア2』の日本公開日が2025年12月5日(金)に決定したということで、ファンのみなさんも楽しみにしていることでしょう。前作『ズートピア』は、ディズニーのアニメ映画として2016年に公開され、社会問題をテーマにしたストーリーや、それをコミカルに描写したキャラクターたちが話題となりました。

補足説明

「ズートピア」の魅力の一つは、動物たちが人間社会のいろいろな側面を反映している点です。例えば、獲物であるウサギと肉食動物が共存するための努力や、偏見への挑戦が描かれています。このテーマは、視聴者に多様性や理解の大切さを再認識させます。

豆知識

また、『ズートピア』はアカデミー賞を受賞したことでも知られています。映画の中には、様々な動物の見た目や性格が反映されており、特に、声優陣も豪華で、ジェニファー・ガーナーや、ジニファー・アニストンといった人気の声優が出演しています。

もしも、前作を振り返りたい方は、ディズニーの公式サイトをチェックしてみてください! ディズニー公式

公開日が決まった『ズートピア2』、新たな冒険が待っているのが楽しみですね!

  • キーワード: ヘビ

ズートピア2 をAmazonで探す



※以下、出典元
▶ 元記事を読む

Views: 0

「ポケモン×マック!ハッピーセット登場」

「ポケットモンスター×マクドナルド」ハッピーセット詳細

2025年7月15日、マクドナルドが発表した特別企画「ポケットモンスター×マクドナルド」に注目が集まっています。今回のキャンペーンでは、3日間限定で配布されるマクドナルド特製のポケモンカードが大きな目玉です。

特に注目したいのが、ピカチュウが描かれたカード。この限定カードは、ハンバーガーやドリンクと一緒に描かれており、ファンにはたまらない特別仕様です。

このピカチュウカードのほかにも、ラルトス、リオル、ニャオハ、ホゲータ、クワッスなど、魅力的なポケモンのカードがランダムで1枚もらえます。それぞれのカードにはマクドナルドの「M」ロゴが入っており、コレクションとしても価値があります。

ハッピーセットおもちゃも見逃せない

さらに、8月8日からスタートするハッピーセットには、ポケモンのおもちゃも登場します。ピカチュウやヒトカゲといった人気ポケモンたちが、おもちゃとして楽しめる予定です。

販売概要

  • ハッピーセット ポケモンおもちゃ開始:2025年8月8日(金)~
  • ポケモンカード特別配布:2025年8月9日(土)~8月11日(月・祝)
  • 実施店舗:全国のマクドナルド店舗
  • 対象:ハッピーセット購入者

ポケモンファンにとって、この3日間限定の特別企画は見逃せません。マクドナルドオリジナルのポケモンカードをぜひ手に入れてください!今後の詳細については、マクドナルドの公式Xで確認することができます。

🧠 編集部より:

「ポケットモンスター×マクドナルド」ハッピーセット詳細

今回のコラボレーションで注目すべきは、3日間限定で配布されるマクドナルド限定ポケモンカードです。この特別なカードは、ハンバーガーやドリンクと共に描かれたピカチュウのデザインが特徴で、通常のカードとは一味違った魅力があります。

限定カードのラインアップ

ハッピーセットには、限定ピカチュウカードのほかにも、ラルトス、リオル、ニャオハ、ホゲータ、クワッスなど、多彩なポケモンたちのカードがランダムで1枚もらえます。さらに、各カードにマクドナルドの「M」ロゴが入っているのも特別感を演出しています。

ハッピーセットおもちゃも見逃せない

2025年8月8日(金)からは、ハッピーセットにポケモンのおもちゃも登場予定です。ピカチュウやヒトカゲなどの人気ポケモンたちがラインアップされ、楽しさ倍増です。おもちゃはコレクターにも注目されるアイテムとなるでしょう。

販売概要

  • ハッピーセット ポケモンおもちゃ開始:2025年8月8日(金)~
  • ポケモンカード特別配布:2025年8月9日(土)~8月11日(月・祝)
  • 実施店舗:全国のマクドナルド店舗
  • 対象:ハッピーセット購入者

ポケモンファンにとって、見逃せない3日間限定の特別企画です。この機会に、ぜひオリジナルのポケモンカードをゲットしてください!

ちょっとした豆知識

実は、ポケモンとマクドナルドのコラボレーションは過去にも行われており、ファンの間で非常に人気があります。このようなイベントは、ポケモンと食事を楽しめる特別な体験として、子供たちだけでなく大人にも支持されています。

また、マクドナルドはアニメのコラボレーションとしても知られており、これまでも多数のキャラクターと提携してきました。

詳細なおもちゃの情報や最新ニュースは、マクドナルドの公式Xで確認できます。

【関連リンク】

  • キーワード: ポケモンカード

ポケモンカード をAmazonで探す

ハッピーセット をAmazonで探す

ポケモンおもちゃ をAmazonで探す



※以下、出典元
▶ 元記事を読む

Views: 0

「北海道産シャウエッセン、味比べ!」

日本ハム「シャウエッセン 北海道 プレミアム」を食べ比べ

本記事では、2023年3月に登場した日本ハムの「シャウエッセン 北海道 プレミアム」を、従来のシャウエッセンと比較しました。この新商品は、北海道産の原料にこだわり、より食べごたえのあるサイズに仕上げられています。

パッケージとサイズの違い

「シャウエッセン 北海道 プレミアム」のパッケージは、中央に北海道のシルエットが描かれたデザイン。通常のシャウエッセンと比べて、サイズも明らかに大きくなっています。内容量はプレミアムが175g、通常のものは117gです。

パッケージの比較

原材料と栄養成分

両製品の主な原材料は類似していますが、「シャウエッセン 北海道 プレミアム」には明記されている北海道産の豚肉と豚脂肪が使用されています。カロリーは100gあたり335kcalで、1袋(175g)あたり586kcalに相当します。

食べ比べの結果

試食では、まずボイルで調理。通常のシャウエッセンは3分、プレミアムは5分茹でました。食べた感覚では、通常のシャウエッセンの皮の食感はしっかりしており、ジューシーさも感じられました。

ボイル後のシャウエッセン

一方、プレミアムはサイズが大きく、弾力や食べ応えが強化されている印象。食べ比べた編集部員からは、肉のほろっと崩れる感覚や、脂の味に微妙な差が感じられたとの意見がありました。

焼き調理の味わい

焼き方でも比較。通常のシャウエッセンは香ばしさがアップし、ジューシーに仕上がりました。プレミアムはさらに脂の味が強く、肉の味わいが濃く感じられました。

焼き上がりのシャウエッセン

まとめと購入情報

「シャウエッセン 北海道 プレミアム」は、希望小売価格591円(175g)で全国のスーパーにて購入可能ですが、Amazonでは在庫切れのようです。食べ応え重視の方には、特にお勧めの一品と言えるでしょう。

自宅での調理方法や食べ比べの体験を通じて、自分のお気に入りを見つけてみてはいかがでしょうか。

🧠 編集部より:

補足説明と背景

日本ハムの「シャウエッセン 北海道 プレミアム」は、2023年に登場し、主に北海道産の材料に注力したウインナーソーセージです。通常のシャウエッセンと比べて、太さや食べ応えが増加しているのが特徴です。今回、本記事ではその違いを詳しく見ていきます。

1. 北海道産原料の重要性

北海道は、日本における高品質な農産物の産地として知られています。特に、豚肉の生産が盛んであり、北海道産の豚肉を使用することで、味や香りの向上が期待できます。このような地域特化型の製品は、消費者に安心感を提供します。

2. 食べ応えの向上

「シャウエッセン 北海道 プレミアム」は、食材が豊富で肉の量も増えているため、食べ応えが強調されています。これは特に、ジューシーさを引き出す要因ともなっており、一口ごとの満足感が向上します。

3. 食感の違い

皮の状態や挽き方によって、両者の食感にも違いが顕著です。北海道 プレミアムの方がボコボコとした印象を持ち、より肉感を楽しむことができると言われています。

4. 調理法と味わい

ボイルと焼き用に調理した場合、それぞれ異なる味わいや香ばしさを体験できるため、食べるシーンや好みに合わせた調理が可能です。焼くことで、さらに香ばしさとジューシーさが際立つため、おすすめです。

豆知識

  • 食文化とウインナー: 日本ではウインナーソーセージは、お弁当や軽食、BBQなど多くのシーンで親しまれています。特に、北海道産は海の幸とともに、食の豊かさを感じられる地域の特性を持っています。
  • 地域連携: 地域産品を利用した製品は、地元の経済活性化にも貢献しています。

関連リンク

このように、シャウエッセン 北海道 プレミアムは、品質、食べ応え、そして地元産素材の魅力を体現した製品として、多くの人の食卓に彩りを与えています。


  • キーワード

    北海道産原料

シャウエッセン 北海道 プレミアム をAmazonで探す 日本ハム をAmazonで探す ウインナーソーセージ をAmazonで探す

※以下、出典元 ▶ 元記事を読む

Views: 0

「西九州ハイエンドオーディオフェア、7/19-20開催!」

第7回 西九州ハイエンドオーディオフェア開催のお知らせ

2025年7月19日(土)と20日(日)の2日間、長崎県で「第7回 西九州ハイエンドオーディオフェア」が開催されます。このイベントは、マックスオーディオが主催し、出島メッセ長崎1階の特設会場で行われます。

イベントの概要

西九州ハイエンドオーディオフェアは、音響機器やオーディオの新技術に興味がある人々にとって、貴重な機会となります。最新のオーディオ製品やシステムを試聴できるだけでなく、専門家との交流を通じて深い知識を得ることもできるでしょう。

重要な視点

  • 参加者のメリット: 音楽愛好家やオーディオエンジニアにとって、自分の耳で最新技術を体験し、プロから直接学ぶことができる絶好の機会です。
  • 地域の文化とのつながり: このようなイベントが長崎で開催されることにより、地域振興や音楽文化の発展につながる点も重要です。

今後のオーディオのトレンドや技術の進化に興味がある方は、是非参加してみてください。

🧠 編集部より:

「第7回 西九州ハイエンドオーディオフェア」は、長崎県で開催される音響機器の展示会です。このイベントは、ハイエンドオーディオに興味がある人々にとって、最新技術や製品を実際に体験できる絶好の機会となります。特に、オーディオマニアや音楽愛好者にとって、ここでしか味わえない音質を楽しむことができます。

補足説明

このオーディオフェアでは、豊富なブランドが参加し、高品質なスピーカーやアンプ、アクセサリーなど、多彩なオーディオ製品が展示される予定です。また、音楽の専門家やメーカーによるセミナーやトークセッションもあるため、知識を深める良い機会となります。

背景情報

実は、オーディオ機器の市場は年々変化しており、特にデジタル化が進んで脱アナログが注目されています。それでも、高級オーディオ市場ではアナログプレーヤーや真空管アンプが根強い人気を誇っています。このフェアは、そんな多様なニーズに応える絶好の場です。

豆知識

興味深いことに、オーディオ機器に対する需要は、音楽の聴き方が変わる中でも根強く、アナログとデジタルのハイブリッドモデルも増えています。最近では、ストリーミングサービスが広がる中、オーナーの好みに応じたカスタマイズができる製品も人気です。

詳細な情報や参加申し込みは、マックスオーディオの公式ウェブサイトをご確認ください。公式サイトへのリンク

  • キーワード: オーディオフェア

オーディオショウ をAmazonで探す
ハイエンドオーディオ をAmazonで探す
特設会場 をAmazonで探す



※以下、出典元
▶ 元記事を読む

Views: 0

AWS製AI統合開発環境”KIRO”の仕様駆動開発でWebアプリを爆速実装! #AIエージェント – Qiita



AWS製AI統合開発環境

こんにちは!ひさふるです。

先ほど(2025年7月14日)、AWS製のAIエージェント搭載IDE”KIRO”のプレビュー版が公開されました!

その実力がどれほどのものか、さっそく触ってみました!

KIROとは?

AWSが開発したAIエージェント搭載の統合開発環境です。

VS Codeなどの代替となるもので、デフォルトでAIエージェントが搭載されているという意味ではCursorに近いでしょうか。

現在のVibe Codingが持つ課題

KIROの設計思想を学ぶ前に、ここ最近の”バイブコーディング”の課題について整理しましょう。

AIを使ったコーディングはプロジェクトの立ち上げに対しては非常に強力に作用し、いわゆるPoC(Proof of Concept、概念実証)の段階では今までと比較にならないほど素早い開発が可能となりました。

しかし、AIによるコーディング(バイブコーディング)を続けていくと気が付かない間に段々と技術負債が蓄積し、いつの間にか可読性皆無のスパゲッティコードが完成していた…なんて経験みなさんも一度はあるのでは無いでしょうか?

そうして生成されたアプリケーションはコードのメンテナンス性が最悪なのはもちろん、Vibe(雰囲気)で仕様を決めてしまったため明文化・体系化されたドキュメントなんてものは無いため、商用環境へのリリースにはとても耐えられない代物に仕上がっていることでしょう。

このような、Vibe(その場の雰囲気)による無秩序な仕様の決定と技術負債の蓄積こそが現在のバイブコーディングの持つ課題であると言えます。

要件定義開発・テスト駆動開発への期待

そこで、そのような無秩序な開発を回避するために、ここ最近では最初にしっかりと仕様やタスクを整理しそれに沿って開発を行う、”要件駆動開発”とも呼べるような手法が良いのでは?と巷で囁かれるようになりました。

また、要件の定義と密接な関係にあるテスト駆動開発も、AIコーディングと相性が良いとされています。

実際、様々な”パイオニア”の方々による工夫・開拓のおかげで、AIコーディングを行っている多くのエンジニアが要件駆動開発に挑戦し始め、そのベストプラクティスを模索し始めていたと思います。

KIROの提示する”要件駆動開発”

KIROは上記のような背景のもと本番環境へのデプロイを見据え、ユーザーのプロンプトから明確な仕様書を生成し、そこから実行すべきタスクを書き出す”仕様(Spec)駆動開発”を達成するために開発されました。(まあ言い方の違いで、ほぼ要件駆動開発と同義でしょうか)

KIROの代表的な実装の流れは、以下のようになっているようです。

  1. ユーザーが入力したプロンプトから要件定義を行う
  2. 定義された要件を達成できるような技術スタックの選定を行う
  3. 1と2の情報をもとに、実際に達成すべきタスクを書き出す
  4. タスクを順に実行し、自律的に実装を行う

これぞまさに、最近(私を含めた)様々な開発者が追い求めていた実装フローそのものでは無いでしょうか!

確かに、この手法の価値自体は既に周知の通りであり、自分でプロンプトを工夫すればGithub CopilotやClaude Codeなどの既存のAIエージェントでも出来ないことはないでしょう。

しかし、KIROはその手法をIDEという形式で提供し、ノウハウに依存せず誰でも簡単に仕様駆動開発をできるようにしたことが、非常にインパクトのある部分ではないでしょうか。

プロダクトの完成度次第では、CursorやClaude Codeに取って代わるような可能性を秘めていると思います。

参考

実際に使って特徴を理解する

事前情報ではとっても凄そうなKIROですが、本当の実力はどれほどのものか、実際に使ってみました。

セットアップ

まずはインストールと最初のセッティングから。公式ページからインストールを行いましょう。

私はMac OSを使っていますが、WindowsとLinuxにも対応しているようですね。

ダウンロードして起動すると最初にログインを求められます。

AWS製なのでAWS Builder IDでログインしたほうが良いかな…と思いつつ、今回はGoogleでログインを行いました。

(ちなみに、Githubでログインしようとしたらエラーが出ました。単に一時的なものだったかもしれませんが…)

スクリーンショット 2025-07-15 1.18.04.png

その後、

  • VS Codeから設定等をインポートするか
  • テーマの選択
  • シェルの設定

などを経て、セットアップは完了です。

今回は素のKIROを触ってみたかったのでVS Codeからのインポートは行いませんでしたが、KIROはVS Code互換となるように作られているので、プロファイルや拡張機能に互換性があるようです。

普段VS Codeを使っている皆さんならすんなり移行できそうですね。

ログインが終わるとプロジェクトを選択する画面に。適当にフォルダを作って開きます。

スクリーンショット 2025-07-15 1.25.21.png

今までのCursorのようなタイプのVibe Codingと、KIROの特徴でもあるSpec(仕様駆動開発)の2つが選べるようですね。

スクリーンショット 2025-07-15 1.38.09.png

プロンプト入力から仕様策定まで

今回はSpecを選択してこんなプロンプトを入れてみます。以前なんとなく思いついたアプリの開発を頼んでみます。

もちろん、具体的な内容は考えていません。

“夢”の実現性を可視化できるWebアプリを作成したいです。以下に実装したい内容を示します。
ユーザーが”夢(目標)”と”達成目標時期”を入力すると、その情報をもとに生成AIが現在のユーザーの状態(夢の達成度や実力など)を聞き返します。
ユーザーが追加で現在の状態を入力すると、それをもとに生成AIが、一般的にその夢を達成するために必要な時間を、今から達成目標時期までの期間で割ることで、1日や1週間あたりに必要な努力量を試算し、夢の達成難易度とアドバイスをユーザーに提示します。
ユーザーはそれをもとに、夢(目標)や達成目標時期を調整することで、実現可能な”夢”をプランニングすることができるようになります。

入力して実行ボタンを押すとAIエージェントが起動しました。requirements.mdというファイルに、要件定義を書き込んでいくようですね。

(DreamComeTrueって名前のアプリにしようと思ってたんですが勝手に名前も決められちゃった…まあいいか…)

スクリーンショット 2025-07-15 1.47.30.png

少し待つと要件定義が完了し内容を確認するように促されます。今回は、次のような5つの機能をメインに考えてくれたようです。

  1. 夢と目標時期の入力 – ユーザーが目標を設定する基本機能
  2. AIによる現状質問 – ユーザーの現在の状態を把握するための対話機能
  3. 努力量と難易度の分析 – 核となる分析・計算機能
  4. 計画の調整 – ユーザーが現実的な計画に修正できる機能
  5. 結果の保存・共有 – 分析結果を活用するための機能

スクリーンショット 2025-07-15 1.50.08.png

概ね良い感じだったのですが、今回はDB等を持たないシンプルなアプリにしたかったので結果の保存・共有は削除してもらいました。

デザインフェーズ(設計書作成)

要件定義が完了すると、ワンボタンで次のデザインフェーズ(計画書の作成)に進めます。

こちらも、少し待つとdesign.mdという形式で計画書が作成されました。

スクリーンショット 2025-07-15 1.56.07.png

シンプルな構成にするために素のHTMLによる実装案を出してきたので、私が普段使っているNext.js+shadcnの構成に切り替えるように指示。

スクリーンショット 2025-07-15 2.02.09.png

1分も経たないうちに、希望通りの設計書が出来上がりました。(mermeidで簡易的な図も出力してくれるのが良いですね!)

実装計画(タスクリスト)の生成

最後に、要件定義書(requirements.md)と設計書(design.md)をもとに、実装計画(tasks.md)が生成されます。

スクリーンショット 2025-07-15 2.02.49.png

テストやデプロイの準備までタスクに含まれており、テスト駆動開発を前提としているところが、最近のAI駆動開発のトレンドをおさえている感じがしてとても良いですね。

タスクリストをもとに実際に開発!

それでは、タスクリストをもとに実装をお願いしてみます。
(どうでも良いけどアイコンが可愛いですよね)

スクリーンショット 2025-07-15 2.04.46.png

環境設定中に各種bashコマンドの実行をして良いか聞かれるので、適宜許可を出してあげます。

単にその場で、実行許可を出す方法のほか、TrustedCommandsに追加することで使えるコマンドを明示的に制御することもできるようです。

スクリーンショット 2025-07-15 2.12.55.png

そういえば本番環境のデプロイまで勝手にされたりしないかな?と心配していたところ以下のようなレスポンスが返ってきました。

次のタスク「2. 型定義とデータモデルの実装」に進む準備が整いました。続けて実装を進めますか?

どうやらタスク1つずつで確認を入れてくれるようですね。安心です。

また、コードやタスクリストの変更はリアルタイムで確認することができるようです。

Claude CodeはCLIツールならではの強みがありましたが、こちらはIDEに統合されたAIエージェントとしての強みを十二分に発揮している様子ですね。

スクリーンショット 2025-07-15 2.19.20.png

更に、tasks.md内では各タスクの直上にStart taskボタンが表示され、ここから直接タスクの実行を指示できそうです。

これは本当にIDEならではの強みですね。

スクリーンショット 2025-07-15 2.25.13.png

デプロイ準備タスクの直前まで終わり、出来上がったアプリがこちら。良い感じです。

スクリーンショット 2025-07-15 3.01.52.png

いくつかバグがありうまく動かない部分もありましたが、気が向いたら修正し、こちらのアプリの詳細も追記しようと思います。

実際にデプロイするところまでやってみても良いかもしれないですね。

おわりに

単純にVS Code互換として設計されている上に、要件定義や設計の質も良いように感じたので、今後は一定数のユーザーを獲得できるのでは無いでしょうか。

もしかしたら実装力やカスタム性はClaude Codeの方が勝るところもあるかもしれませんが、単に要件定義ツールとしての運用でも十分に効果を発揮するように感じました。

使ってみた所感としては非常に満足で、今後の使用感次第ではお気に入りツールの1つになってくれそうな可能性を感じました。

最後までお読みいただきありがとうございました!

雑記

今日、ちょうど会社の懇親会でエンジニアの学習や能力判断についての話題が上がっていたところでした。

ほんの数年前までの新卒エンジニア採用の場では、簡単なWebアプリでも十分にポートフォリオとして提出できましたが、昨今はそれだけでは実力の判断が難しくなってしまっていますよね。

KIROの登場により、理路整然とした設計や仕様策定すら誰でもできるようになってしまったので、新卒エンジニア採用の場で何を基準として能力の判断を行うかは、非常に難しい課題となりそうですね。





Source link

Views: 0

GitHub Self-hostedに移行しました。CIが最大55%速くになり、月額が300万円節約できた!


こんにちは、SODAのSREチームのDucと申します。

GitHub Actionsのコストを削減しながらCIワークフローを高速化したの工夫をご紹介します。

私たちのチームは、snkrdunk.comサイトとSNKRDUNKモバイルアプリの可用性とパフォーマンスの維持に注力しています。
それに加えて、クラウドインフラストラクチャやその他の監視・開発ツールのコスト管理も担当しています。

毎月、AWSやGitHubなどのインフラストラクチャとツールの請求書をチェックしています。
GitHubの請求額が非常に高いことに気づきました。特にGitHub Actionsの部分です。
参考までに、GitHub Actionの使用量とサーバーの本番ワークロード費用の比較をご紹介します。

  • Fargate: Savings Plan適用で月額約$7,000。私たちのサービスは平均約5000リクエスト/秒のトラフィックがあります
  • GitHub Actions: 予期しないコストを避けるため月額$9000で予算を上限設定していますが、定期的にこの閾値を超えるため、CICDパイプラインが完全に停止することを防ぐために予算を引き上げる必要があります。たまにはGitHubの請求額が$18,000に達することもありました。

GitHubは2種類のランナーを提供しています:GitHub-hosted Runner(Microsoftが2018年にGitHubを買収して以来Azureで動作)とself-hosted runnerです。

https://github.com/features/actions

GitHub-hostedはUbuntuにプリインストールされたソフトウェアが付属しており、あらゆる種類のプログラミング言語で非常に使いやすく、しかしかなり単価が高いです。

Specs GitHub-hosted EC2 On-demand EC2 Spot
x86 2コア、8GBメモリ、75GBディスク、Public IP付き $0.008 $0.001818(-77%) $0.000735(-90.8%)

Note: EC2のは北バージニアリージョン、m7i-flex.largeタイプを使用する

では、どのように実現するのでしょうか?

Googleで簡単に検索したところ、2つのリポジトリが目に留まりました。

  • Runs-onプロジェクト: https://github.com/runs-on
  • Philips Labs AWS self-hosted runnerプロジェクト: https://github.com/github-aws-runners/terraform-aws-github-runner
    どちらもオールインワンソリューションで、非常に良くドキュメント化されており、デプロイも簡単です。
    私たちのIaCはTerraformなので、Phillips LabsのTerraformモジュールを選択しました。
    注:Runs-onは商用目的で使用する場合、ライセンス料(年間$300)が必要です。
    このモジュールのアーキテクチャは以下の通りです。

Terraformモジュールのパラメータを設定するだけで、簡単にできるはずですよね?
モジュールをセットアップし、terraform applyを実行し、Organization設定でGitHub Appを登録すると、ダミージョブが期待通りにピックアップされました。

self-hostedランナーが正常に起動できたのを確認できたので、次はすべてのテストワークフローをself-hosted runnerを使用するように変更しました。数日後、いくつかの問題発生しました。

  • 試算の通りににコストが安くならなかった
  • Docker Hubのレートリミット
  • スポットインスタンスがAWSから回収されるため、self-hosted ランナーが強制的に停止られる
  • ジョブのキュー時間がGitHub-hosted Runnerと比較してかなり長い
  • 一部のジョブが「queued」状態で永遠に詰まる

試算の通りににコストが安くならなかった

数日後、請求書をチェックして、コストが非常に高いことに驚きました。
このプロジェクトに割り当てたタグでCost Explorerに日割りのコストを確認すると、90%はNAT Gatewayの費用でした。

当初、すべてのランナーインスタンスをプライベートサブネットに配置していたため、インターネットと通信する際にNAT Gatewayを使用する必要がありました。
ジョブを実行する前に以下の手順を行う必要があります。

  1. GitHubワークフローを実行するために必要なソフトウェアをインストールする(curl, git, dockerなど)
  2. ランナーはGitHub Action runner binaryを取得する

さらにジョブを実行するの際に必ず下記のステップが繰り返します。

  1. git checkout
  2. Dockerイメージを取得する

AWSはネットワークに入るデータには課金しませんが、NAT Gatewayを使用する場合、方向に関係なく、NAT Gatewayを通過するデータに対して課金します。
ランナーインスタンスの再利用時に発生する奇妙なエラーを避けるため、エフェメラルランナーを使用しました。これは、すべてのジョブが新しいインスタンスを取得し、完了時にインスタンスが廃止されます。また、上記のすべてのステップが繰り返し実行されるので、NAT Gatewayを通過する大量のネットワークトラフィックが発生しました。

インターネット通信を可能な限り最小限に抑えるため、アーキテクチャにいくつかの変更を行いました。

  • 何もないベースイメージからランナーを作る代わりに、カスタムAMIをビルドして使用します。これにより、ランナーがジョブが実行できる状態までの時間が短縮されます。AMI内で、ワークフローで使用するすべてのソフトウェア(我々の場合はCGO用のCライブラリ、Golangマイグレーションツールなど)とDocker image(Golang、MySQL、Redisなど)を準備します。
    (Phillips Labsのモジュールは、カスタムAMIをビルドするためのPackerテンプレートのサンプルも提供しています)
  • Docker Hubからのイメージプル回数を減らし、彼らのレートリミットを避けるため、VPCエンドポイントでプルスルーキャッシュ設定のあるAWS Public ECRに切り替えました。

もう一つの選択肢は、プライベートサブネットの代わりにパブリックサブネットを使用することです。そうすると、各インスタンスに公開IPv4が付与され、独自にインターネットと通信できるため、NAT Gatewayは不要になります。しかし、これもまた、ランナーインスタンスがライフタイム中にインターネットに露出することを意味するため、最低限の通信のみの許可を設定しましょう。

結果として日額コストが$800から約$100に削減できました。

Docker Hubのレートリミット

私たちの1つのテストジョブにはい8つの公式のDockerイメージが必要です。
しかし、Docker Hubには未ログインユーザーに対して、1つのIPv4に対して6時間以内に100回までしかPullできません。

https://docs.docker.com/docker-hub/usage/


という意味すると、6時間に12ジョブしか実行できません。これは非常に厳しいレートリミットです。

(弊社ではDocker HubでTeam Planを購入しているため、Team Planのユーザーでログインすることでpull rateは無制限になりますがジョブにログインステップが増えてしまいますし、CI専用のアカウント管理の必要が新たに発生するため、Team Planのユーザーでログインすることは避けました)

GitHub-hostedでは問題ありません。すべてのジョブが新しいマシンと新しいIPv4を取得するためです。しかし、NAT Gatewayでは、すべてのインスタンスが限られたIPでDocker Hubと通信するため、Docker Hubから409エラーが発生する可能性が非常に高くなります。
そこで、ECR Public + プルスルーキャッシュ + AWS VPC Endpointに切り替えました。
ECR publicには、ほぼ有名なDockerリポジトリ(Golang、Redis、MySQLなど)があるため、必要なリポジトリを簡単に見つけることができるはずです。
但し、Docker HubのイメージとECRのイメージが異なることに少し懸念を持っています。そこでdocker scoutコマンドを使用して確認してみました。

docker scout compare --to golang:1.24.3-bullseye public.ecr.aws/docker/library/golang:1.24.3-bullseye
    i New version 1.18.0 available (installed version is 1.17.0) at https://github.com/docker/scout-cli
    ! 'docker scout compare' is experimental and its behavior might change in the future
    ✓ SBOM obtained from attestation, 298 packages found
    ✓ Provenance obtained from attestation
    ✓ SBOM of image already cached, 298 packages indexed
   
  
  
                      │                                  Analyzed Image                                   │                                 Comparison Image                                   
  ────────────────────┼───────────────────────────────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────
    Target            │  public.ecr.aws/docker/library/golang:1.24.3-bullseye                             │  golang:1.24.3-bullseye                                                            
      digest          │  cd43396a4113                                                                     │  cd43396a4113                                                                      
      tag             │  1.24.3-bullseye                                                                  │  1.24.3-bullseye                                                                   
      platform        │ linux/arm64/v8                                                                    │ linux/arm64/v8                                                                     
      provenance      │ https://github.com/docker-library/golang.git                                      │ https://github.com/docker-library/golang.git                                       
                      │  6f5593131e9bccda9a4e83f858427d4d0d16b58d                                         │  6f5593131e9bccda9a4e83f858427d4d0d16b58d                                          
      vulnerabilities │    0C     1H     3M   124L                                                        │    0C     1H     3M   124L                                                         
                      │                                                                                   │                                                                                    
      size            │ 280 MB                                                                            │ 280 MB                                                                             
      packages        │ 298298                                                                                
                      │                                                                                   │                                                                                    
    Base image        │  buildpack-deps:4724dfb3ebb274c6a19aee36c125858295ad91950e78a195b71f229228a6aaeb  │  buildpack-deps:4724dfb3ebb274c6a19aee36c125858295ad91950e78a195b71f229228a6aaeb   
      tags            │ also known as                                                                     │ also known as                                                                      
                      │   • bullseye-scm                                                                  │   • bullseye-scm                                                                   
                      │   • oldstable-scm                                                                 │   • oldstable-scm                                                                  
      vulnerabilities │    0C     1H     3M    63L                                                        │    0C     1H     3M    63L                                                         
  
  
      GOLANG_VERSION=1.24.3
      GOPATH=/go
      GOTOOLCHAIN=local
      PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  
  
  
       298 packages unchanged

ご覧の通り、出力された表のAnalyzed ImageとComparison ImageでTarget以外の行に差分がないことが確認できました。

スポットインスタンスがAWSから回収されるため、self-hosted ランナーが強制的に停止してしまう

コストを最適化するため、USリージョン(他のリージョンと比較して最も安価)でスポットインスタンスを活用しています。しかし、このスポットインスタンスタイプであるため、AWSが他の顧客のために必要とする場合はいつでも終了される可能性があります。
しかし、終了率を減らす手段があります。
デフォルトでは、EC2 Fleet APIはスポットインスタンスを取得の際にlowest price戦略を使用します。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html

  • Lowest price -> デフォルト
  • Diversified
  • Capacity optimized -> 最低終了率
  • Price capacity optimized -> 最良の価格-終了率

終了率はAZ間で同じではありません。より多くの容量を余裕を持って持つAZでは、終了率が低くなるはずです。モジュールのinstance_allocation_strategyパラメータで取得戦略を変更できます。

上記の画像からわかるように、capacity optimized戦略に切り替えた後、ランナーの終了率が大幅に改善されました。
(EC2での実行はGitHub-hostedよりも大幅に安価であるため、スポットでの少し高いコストは許容可能だと考えており、また、開発者がPRでジョブを再試行する必要が少なくなるため、より良い体験を提供します)

ジョブのキュー時間がGitHub-hosted Runnerと比較してかなり長い

これには2つの理由がありました。

  • 準備ステップ(Dockerインストール、Action binaryセットアップ)は、ランナーが起動する際に少なくとも1分かかる必要があります。これは上記で説明したカスタムAMIを使用することで解決できます。
  • EC2のクォータ。
    通常、本番ワークロードには東京リージョンを使用しているため、他のリージョンのクォータ制限にあまり気にしておりません。
    最初の理由については、ランナーは1分程度でジョブを実行する準備が整うはずですが、なぜかそれよりジョブが開始までの時間が長くかかりました。
    スケールアップlambda関数のログを調べたところ、EC2 Fleet APIを呼び出す際にいくつかのエラーが見つかりました。それはMaxSpotInstanceCountExceededエラーでした。これは、AWSのクォータに達したためスポットリクエストが失敗したことを意味します。しかし、AWSコンソールでクォータをチェックしたところ、その時点まだ上限緩和申請はまだ指してなかったですが、制限はランダムな数字(648)でした。
    スポットインスタンス制限クォータはのソフトリミットであることが判明しました。AWSは顧客の使用量を継続的に監視し、必要に応じて段階的に増加させます。しかし、私たちの場合、すべてのテストをself-hosted runnerを使用するように一気に切り替えたため使用量が突然増加し、このプロセスが追いつかず、制限エラーが発生しました。
    妥当な制限をリクエストした後、キュー時間が大幅に短縮されました。

一部のジョブが「queued」状態で永遠に詰まる

時々、複数の並列ジョブを持つワークフロー内で、その一部のみがqueued状態に詰まります。GitHubコンソールは何も出力しないため、キューに入っているジョブがEC2に割り当てられているかどうか分かりませんでした。インスタンスIDがないため、どのインスタンスに問題があるかを特定できません。

アーキテクチャを考慮すると

以下のすべてのログをチェックしました。

  • GitHub Apps
  • API Gatewayアクセスログ
  • Webhook Lambdaログ
  • Scale-up Lambdaログ
    スケールアップLambdaログに以下のようなログが含まれていることがわかりました。
{
    "level": "INFO",
    "message": "Created instance(s): i-06486eac2256681ca",
    "timestamp": "2025-07-01T10:51:09.772Z",
    "service": "runners-scale-up",
    "sampling_rate": 0,
    "xray_trace_id": "1-6863bd99-21c88f07e1a5a3e8328e7200",
    "region": "us-east-1",
    "environment": "gh-ci-x64-2core-cpu-optimized",
    "module": "runners",
    "aws-request-id": "cd33581c-5b7d-575e-b3c2-38c1e4a99eec",
    "function-name": "gh-ci-x64-2core-cpu-optimized-scale-up",
    "runner": {
        "type": "Org",
        "owner": "repo-owner",
        "namePrefix": ""
    },
    "github": {
        "event": "workflow_job",
        "workflow_job_id": "45123342099"
    }
}

GitHubコンソールを見ると、ジョブIDはURLの末尾の部分であることがわかります。

https://github.com/{org}/{repository}/actions/runs/{workflow_run_id}/job/{job_id}

ジョブIDがあれば、ジョブがどのインスタンスにも割り当てられているかどうかを確認できます。
しかし、ジョブが詰まった場合、ジョブIDで検索してみるとそのジョブのインスタンスが正常に作成され、正常に実行されていることが見えました!これは非常に不思議でした。
色々調べた結果、これはAction Runner binaryのバグであることが判明しました。

https://github.com/actions/runner/issues/3609

何らかの理由で、ランナーインスタンスはジョブを拾いましたが、GitHubにログをプッシュしてステータスを報告することができず、永遠にqueued状態に詰まります。このバグは現時点でもまだ解決されていないようです。
(AWSとAzureまたはGitHub間の接続問題に何らかの内部レート制限があると推測します)

進めないジョブについては、コンソールから手動でワークフローをキャンセルして再実行できます。しかし、ほぼ100近いのジョブをチェックして、本当に動かなかったのか、それとも実行順番を待っているだけなのかを確認するのは非常に面倒です。
最終的に、シンプルな対策を思いつきました。
GitHub-hosted runnerを使用して、15分ごとに実行されるスケジュールワークフローを実行し、15分以上キューに入っているジョブを含むワークフローがあるかどうかをチェックします。ある場合は、そのワークフローを強制的にキャンセルして再実行させます。

jobs:
  retry-workflows:
    runs-on: ubuntu-24.04
    name: Retry Queued Workflows
    steps:
      - name: Check and retry queued workflows
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
            QUEUED_RUNS=$(gh api --method GET /repos/{org}/{repository}/actions/runs -F status=queued --jq '.workflow_runs[] | .id')
            CURRENT_TIME=$(date +%s)
            for run_id in $QUEUED_RUNS; do
                QUEUED_JOBS=$(gh api --method GET /repos/{org}/{repository}/actions/runs/"$run_id"/jobs --jq '.jobs[] | select(.status=="queued") | .id')
                for job_id in $QUEUED_JOBS; do
                    # Get the created_at timestamp for the run
                    CREATED_AT=$(gh api --method GET /repos/{org}/{repository}/actions/jobs/"$job_id" --jq '.created_at')
                    CREATED_TIME=$(date -d "$CREATED_AT" +%s)

                    
                    QUEUED_MINUTES=$(( ("$CURRENT_TIME" - "$CREATED_TIME") / 60 ))

                    echo "The job_id $job_id in the workflow $run_id has been queued for $QUEUED_MINUTES minutes"

                    
                    if [ "$QUEUED_MINUTES" -ge 15 ] && [ "$QUEUED_MINUTES" -le 120 ] ; then
                        echo "Processing workflow run $run_id"
                        gh run cancel "$run_id"
                        sleep 5
                        for i in {1..5}; do
                          if gh run rerun "$run_id"; then
                            break
                          fi
                          echo "Retry $run_id attempt $i failed. Waiting 5 seconds before next attempt..."
                          sleep 5
                        done

                        break
                    fi
                done
            done

これにより、スタックしたジョブを手動でキャンセルして再試行する必要がなくなりました。

一時パーティションサイズ(tmpfs /tmp)が枯渇

カスタムAMIのベースイメージとしてAmazon Linux 2023を使用しています。しかし、このLinuxディストリビューションには注意点があります。

https://docs.aws.amazon.com/linux/al2023/ug/compare-al2-al2023-tmp.html

/tmpパーティションは、RAMの50%のサイズ制限と100万inodeの最大値を持つtmpfsファイルシステムです。
/tmpをキャッシュに使用する予定がある場合は、非常に速く枯渇になり、ワークフローが失敗する可能性があるため十分注意してください。
代替案として/var/tmp(EBS上)を使用できます。

ジョブの仕様に基づくランナーインスタンスの適切なサイジング

EC2インスタンスを使用することでランナーの価格が大幅に削減されたため、ランタイムを最速化するためにインスタンスをスケールアップ余裕があります。
しかし、すべてのジョブがより多くのCPUコアとメモリを活用できるわけではありません。例えば、私たちのgo testはシリアルとパラレルに分かれており、パラレルジョブのみがより多くのCPUコアを持つインスタンスで高速に実行されます。
EC2利用のきっかけで、CloudWatchを使用してリソースメトリクスを収集し、必要に応じてインスタンスをスケールアップできます。
しかし、GitHub-hosted runnerを使用している場合でも、これは可能です。

https://github.com/marketplace/actions/workflow-telemetry

このGitHub Actionは、ランナーがジョブを実行する際にすべてのメトリクスを収集し、結果をワークフローサマリーに投稿します。

Workflow Telemetryの結果をチェックした後、一部のジョブが多くのCPUコアを活用できることが分かりました。これは、mインスタンスタイプ(CPU-メモリ比が1:4)の代わりに、より良い価格/パフォーマンスのためにcインスタンスタイプ(CPU-メモリ比が1:2)を変更しました。
一方、GitHub-hostedは、CPU-メモリ比がEC2 mインスタンスタイプに等しい1種類の汎用インスタンスのみを提供します。

https://docs.github.com/en/actions/concepts/runners/about-larger-runners

これは単純な例です。ワークフローが他のインスタンスタイプ(ネットワーク重視、メモリ重視、GPUインスタンスなど)を活用できる場合、自由にそれらに変更できます。

キャッシュバックエンドをGitHub cacheからS3に切り替え

GitHub Actionsには、ランタイムを短縮するためにジョブとワークフロー間でファイルをキャッシュバックエンドがあります。
しかし、どのプランでも各リポジトリは最大10GBのみです。私たちのリポジトリは少し複雑で、10GBでは不十分で、キャッシュファイルがGitHubによって頻繁に削除されていました。

EC2でself-hostedに移行したため、S3をキャッシュストレージとして使用する方が適切だと思います。利点としては

  • 無制限の容量である
  • S3 Gateway Endpointを使用するとスピードがすごく速い(実質300~400MB/sである。一方、GitHub Action Cacheは50~100MB/sだけ)
    上記で話したruns-onプロジェクトは、actions/cache actionの代わりのactionがあります。

https://github.com/runs-on/cache

  AWS_REGION
  RUNS_ON_S3_BUCKET_CACHE

上記の2つの環境変数を追加し、EC2ランナーがS3バケットに適切にアクセスする権限を持っていることを確認を取れれば、利用できます。
他のパラメータはactions/cacheと同じで、S3を使用できない場合は自動的にGitHub Action Cacheにフォールバックしてくれます。

ステップ間のキャッシュ問題を修正

これはself-hostedとはあまり関係ありませんが、最適化にの工夫を紹介させていただきます。

私たちのテストワークフローには以下のステップがあります

  1. 変更にテストを実行する必要があるファイル(*.go*.sqlなど)が含まれているかチェック
  2. タグに基づいてテストをいくつかの並列ジョブに分割
  3. 各ジョブ内で
  • ソースコードをチェックアウト
  • docker composeでDockerコンテナを準備(go mod download、MySQL、Redisなど)
  • マイグレーションを実行
  • テストを実行する

テストワークフローはこのようになります。

そして、各ジョブ内のステップはこのようになります

ご覧の通り、Setup backendsは約3分30秒がかかるし、すべての並列ジョブで同じく繰り返します。
5分または6分しか消費しないジョブにとって、これはランタイムの50%です!
そこで、ワークフロー全体を高速化するために以下のことを行いました。

MySQLコンテナをキャッシュする

MySQL公式イメージを使用していますが、データベースはテストを実行する前に日本語の設定が必要なため、実行前にビルドする必要があります。

ビルドは約30秒かかります。しかし、MySQL設定はめったに変更されないため(MySQLバージョンアップぐらい)、すべてのジョブで繰り返しビルドする必要はありません。
そこで、すべてのテストを実行する前にMySQL Buildステップを追加しました。

  1. カスタムDockerfileとその他のMySQL設定ファイルを含むetc/mysqlフォルダのハッシュをチェックを行う
  2. ハッシュキーをキャッシュキーとして使用し、ビルドされたコンテナがキャッシュに存在するかどうかを確認する
  3. 存在しない場合、ビルドコマンドを実行する
  4. MySQLコンテナをディスクに保存し、ファイルをアーカイブしてキャッシュ(S3)にプッシュしする
mysql-build:
    runs-on: self-hosted-linux-x64-4core-cpu-optimized
    name: Building MySQL image
    steps:
      - name: Checkout
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 
        with:
          sparse-checkout: |
            etc/docker/mysql
            docker-compose.ci.yml

      - name: Get mysql folder hash
        run: echo "MYSQL_IMAGE_HASH=$(git ls-files -s etc/docker/mysql | git hash-object --stdin)" >> "$GITHUB_ENV"

      - name: Check if cache exists
        id: cache-hit-check
        uses: runs-on/cache/restore@5a3ec84eff668545956fd18022155c47e93e2684 
        env:
          RUNS_ON_S3_BUCKET_CACHE: dummy-bucket
        with:
          path: /tmp/docker-build/mysql
          lookup-only: true
          key: test-${{ runner.os }}-${{ runner.arch }}-snkrdunkcom-mysql-${{ env.MYSQL_IMAGE_HASH }}

      - name: Build mysql image
        if: ${{ steps.cache-hit-check.outputs.cache-hit != 'true' }}
        run: |
          cp etc/docker/.env.default etc/docker/.env
          docker compose -f docker-compose.ci.yml build mysql

      - name: Cache preparation
        if: ${{ steps.cache-hit-check.outputs.cache-hit != 'true' }}
        run: |
          mkdir -p /tmp/docker-build/mysql
          docker save -o /tmp/docker-build/mysql/snkrdunkcom-mysql.tar snkrdunkcom-mysql

      - name: Saving mysql image
        if: ${{ steps.cache-hit-check.outputs.cache-hit != 'true' }}
        id: save-mysql-image
        uses: runs-on/cache/save@5a3ec84eff668545956fd18022155c47e93e2684 
        env:
          RUNS_ON_S3_BUCKET_CACHE: dummy-bucket
        with:
          path: /tmp/docker-build/mysql
          key: test-${{ runner.os }}-${{ runner.arch }}-snkrdunkcom-mysql-${{ env.MYSQL_IMAGE_HASH }}

その後、各テストジョブで、S3からMySQLコンテナをダウンロードして、インポートします。

docker load  /tmp/docker-build/mysql/snkrdunkcom-mysql.tar

Docker composeファイル内の同じ名前で、MySQLコンテナは再びビルドされるべきではありません。
したがって、ランタイムに30秒かかるカスタムMySQLコンテナをビルドする代わりに、今ではS3からコンテナファイル(約350MB)をダウンロードするのに約1秒、インポートするのに約5秒しかかかりません。

マイグレーションされたデータベースのキャッシュ

テストを実行するには、スキーマを準備するためにマイグレーションコマンドを実行する必要があります。2018年に始まった私たちのサービスは、現在550以上のマイグレーションステップを実行する必要があります。

このステップは各ジョブで合計150秒以上かかります!
しかし、すべての変更にデータベースマイグレーションが含まれているわけではありません。
そこで、すべてのテストジョブの前に、データマイグレーションステップを実行するだけのジョブを追加しました。

  1. /migrationsフォルダのハッシュをチェックする
  2. ハッシュキーをキャッシュキーとして使用し、マイグレーションされたデータベースファイルがキャッシュに存在するかどうかを確認する
  3. 存在しない場合、MySQLコンテナを起動し、マイグレーションコマンドを実行する
  4. MySQLコンテナを停止し、データベースファイルをアーカイブしてキャッシュ(S3)に保存する
db-migrate:
    runs-on: self-hosted-linux-x64-4core-cpu-optimized
    name: Database migration
    steps:
      - name: Checkout
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 

      - name: Get migration hash
        run: echo "MIGRATION_HASH=$(git ls-files -s migrations | git hash-object --stdin)" >> "$GITHUB_ENV"

      - name: Check if migration cache exists
        id: cache-hit-check
        uses: runs-on/cache/restore@5a3ec84eff668545956fd18022155c47e93e2684 
        env:
          RUNS_ON_S3_BUCKET_CACHE: dummy-bucket
        with:
          path: /var/tmp/db_data
          lookup-only: true
          key: test-${{ runner.os }}-${{ runner.arch }}-db-migration-${{ env.MIGRATION_HASH }}

      - name: Setup db
        if: ${{ steps.cache-hit-check.outputs.cache-hit != 'true' }}
        run: |
          cp etc/docker/.env.default etc/docker/.env
          docker compose -f docker-compose.ci.yml up -d mysql
          docker run --network snkrdunkcom_default jwilder/dockerize:v0.9.3 -wait tcp://mysql:3306 -timeout 3m
          docker compose exec mysql mysql -uroot -psnkrdunk -e 'SET GLOBAL default_collation_for_utf8mb4=utf8mb4_general_ci'
          make migrate-up DB_NAME=snkrdunk_test

      - name: Cache preparation
        if: ${{ steps.cache-hit-check.outputs.cache-hit != 'true' }}
        run: |
          docker compose -f docker-compose.ci.yml down
          sudo chmod -R 775 /var/tmp/db_data/

      - name: Saving DB migrated data for test
        if: ${{ steps.cache-hit-check.outputs.cache-hit != 'true' }}
        id: save-migrated-db-data
        uses: runs-on/cache/save@5a3ec84eff668545956fd18022155c47e93e2684 
        env:
          RUNS_ON_S3_BUCKET_CACHE: dummy-bucket
        with:
          path: /var/tmp/db_data
          key: test-${{ runner.os }}-${{ runner.arch }}-db-migration-${{ env.MIGRATION_HASH }}

マイグレーションされたデータがすでにデータベースに読み込まれているため、各ジョブで毎回150秒かかるマイグレーションコマンドを実行する代わりに、今ではMySQLデータファイル(約31MB)をダウンロードするのに1秒未満しかかかりません。

go mod downloadのキャッシュ

これはテストジョブの前にgo mod downloadを実行し、Golangコンテナがそれを再実行しないように変更しました。

結果

結局、私たちのワークフローは

から

に変わりました

結果として、DataDogのCI Pipeline Visibilityで確認したところ

CIランタイムが大幅に短縮されのが見えています🎉
GitHub Action Performance Metricsの数値からみると、私たちのジョブは以前より平均 20% 高速になり、最良のシナリオでは最大 54% 速くなりました。

Test Workflow Old (sec) New (sec) Change
Test Workflow 1 394.4 279.7 29.1%
Test Workflow 2 311.3 233.1 25.1%
Test Workflow 3 443.4 374.4 15%
Test Workflow 4 495.3 548 -10%

※ Workflow中の各ジョブ平均実行時間で計算しました。

削減できたコストについては、毎月ワークロードが変わるので、移行前と移行後の請求書を比較するのはできないため、移行後実際利用量(分数)をGitHub Usage Metricsからを取って、GitHub-hostedを利用する場合、いくらかかるべきのか計算しました。

参照: https://docs.github.com/en/billing/managing-billing-for-your-products/about-billing-for-github-actions

Machine Type Total minutes Price per min Total Cost (USD)
linux-x64-2core 4845 0.008 38.76
linux-x64-4core 622319 0.016 9957.104
linux-x64-8core 416835 0.032 13338.72
linux-arm64-2core 145365 0.005 726.825
linux-arm64-4core 1400 0.01 14
linux-arm64-8core 116 0.02 2.32
Total cost in case of GitHub-Hosted 24077.729

ご覧の通り使用量はGitHub-hostedで $24,000 かかるべきでしたが、self-hostedに移行した後ただ $3000 だけかかりました💸
これは 87.5% のコスト削減です!

  • Self-hostedは、オンデマンドインスタンスでもGitHub-hostedよりはるかに安いです。
  • スポットインスタンスを使用する場合、より良い終了率のためにデフォルトのインスタンス取得戦略を変更することを忘れないでください。
  • CICDパイプラインを最適化するためにランナーを積極的にカスタマイズできます。
  • CI監視は非常に便利です。DataDog CI Pipeline Visibilityについては弊社別のブログ記事もあります:https://zenn.dev/team_soda/articles/b10194a91dbd34
  • 永遠に詰まる「Queued」ジョブに十分注意してください。原因は色々があるかと思います。

Self-hostedに移行してから2ヶ月経ちました。最初想定できなかったシナリオが多かったですが、少しづつ潰して、現在だいぶ安定になりました。
運用コストがちょっと増えてきましたが、コストとカスタマイズのメリットはすごく大きい感じました。
ぜひやってみてください!

また、メンバーを常に募集しているので、ぜひ採用ページだけでも覗いてみてね☺️

https://recruit.soda-inc.jp/



Source link

Views: 0

「宇宙のスープ」を再現!数兆度の神秘に迫る✨

📌 ニュース:
宇宙誕生直後、「原始スープ」と呼ばれる超高温・高密度の状態が存在しました。国際研究チームは地球上でこの極限状態を再現し、冷却過程で濃厚な「後味が残る」ことを発見しました。この状態で素粒子たちは自由に動き、生成されたクォークグルーオンプラズマ(QGP)はまるで「素粒子のパーティー」のような状況を示します。

衝突実験を通じて得られたデータは、宇宙誕生の貴重な手がかりとなります。重粒子の動きすら冷却過程やエネルギー損失に影響を与えており、この「後味」を調査することで宇宙の進化をより深く理解できる可能性があります。

  • この記事のポイントを3つご紹介しますね✨

    1. 宇宙の「原始スープ」再現🥣
      国際研究チームが、宇宙誕生直後の超高温・高密度の環境を地球上の実験室で再現しました。これにより、原始スープが冷める際に「濃厚な後味」が残ることが分かりました。

    2. 素粒子たちの動き🔍
      宇宙が誕生した瞬間、素粒子たちは自由に動き回れました。この状態を「クォークグルーオンプラズマ(QGP)」と呼び、後に冷却されることで安定した粒子(ハドロン)に戻ります。この過程での粒子のふるまいは、宇宙の起源を探る鍵となります。

    3. 冷却過程の重要性💡
      最近の研究で、冷却段階での粒子同士の相互作用が宇宙誕生の「後味」に大きな影響を及ぼすことが明らかになりました。この発見は、宇宙誕生に関する新たな洞察を提供し、今後の研究の重要性を示しています。


※以下、出典元
▶ 元記事を読む

Views: 0

参院選情勢、自公過半数割れの危機!若者の自民離れ加速中

【参議院選挙】最新情勢:自公“過半数割れ”の可能性と若者の自民党離れ

TBS NEWS DIGの報道によると、現在進行中の参議院選挙では、自民党と公明党の連立与党が過半数を割る可能性が高まっています。この分析は、JNNによる中盤情勢の結果に基づいています。

自公の議席数動向

今回の選挙では、125議席が争われており、与党が過半数を維持するためには50議席が必要です。報告によると、以下のような議席予想がされています:

  • 自民党: 現在の52議席から28~44議席へ減少する予測
  • 公明党: 現在の14議席から5~11議席へ減少
  • 立憲民主党: 22議席から24~32議席へ増加
  • 国民民主党: 4議席から11~21議席への増加が期待されている
  • 参政党: 1議席から10を超える議席獲得の可能性

自民党と公明党は同時に議席を減らす見込みであり、これは、前回の選挙結果や序盤の情勢と比べて厳しい状況にあることを示しています。特に、野党の立憲民主党や国民民主党、参政党が好調に議席を伸ばしているというポイントが注目されています。

1人区の重要性

選挙戦のカギを握るのが「1人区」です。前回の選挙では与党が圧勝しましたが、今回の中盤情勢では、与党優勢が8、野党優勢が15に変化しており、全国的に与党が苦戦している様子が見られます。

若者層の自民党離れ

特に顕著なのは、若者層の自民党離れです。2022年との比較で、自民党の支持率が大幅に低下しています。具体的には、20代以下の支持率は約半減し、今回の比例投票先調査では、国民民主党が最も支持を集めていることも明らかになっています。

  • 20代以下の比例投票先:
    • 自民党: 7.2%
    • 公明党: 5.0%
    • 国民民主党: 14.9%

この変化は、ソーシャルメディアの普及が影響しているとされ、多くの若者がネット上の情報をもとに投票行動を決定する傾向が強まっています。

今後の展望

選挙を控えたこの情勢の変化は、有権者の態度が最後の数日で大きく変わる可能性を示唆しています。特に若者層の動向が、選挙結果に与える影響は計り知れません。是非、引き続き注視していきたいところです。

選挙の行方次第で、今後の政治情勢が大きく変わる可能性があるため、有権者としての決定がどのように形成されるかが重要です。

🧠 編集部より:

参議院選挙の最新情勢についての補足説明

今回の参議院選挙についての現状は、自民党と公明党が過半数を割り込む可能性が高まり、特に若年層を中心とした自民党離れが大きな要因として挙げられています。選挙は125議席が争われ、過半数を維持するには50議席が必要となります。JNNの調査によれば、与党である自民党と公明党は議席を減らす見込みで、野党の立憲民主党や国民民主党、さらに新興の参政党が議席を伸ばす傾向にあります。

最新情勢の要点

  • 与党の議席予測

    • 自民党:28〜44議席
    • 公明党:5〜11議席
  • 野党の議席予測

    • 立憲民主党:24〜32議席
    • 国民民主党:11〜21議席
    • 参政党:8〜18議席

若者の投票動向

特に注目すべき点は、20代以下の若年層の自民党支持率が急落していることです。2022年には22.8%だった支持率が、今回の調査で9.1%にまで減少しています。この傾向は30代でも同様で、若年層の投票先として国民民主党や参政党が上昇しています。

  • 20代以下の比例投票先
    • 自民党:7.2%
    • 公明党:5.0%
    • 国民民主党:14.9%
    • 参政党:10%

興味深いトピックス

  • 1人区の動向
    1人区の結果が選挙結果を左右する可能性が高く、過去の選挙結果を踏まえると、現在の与党優勢が減少し、野党系優勢の区域が増えていることが分かります。特に、保守王国とされる地域での自民党の苦戦が目立ちます。

  • ソーシャルメディアの影響
    若者の投票意向において、ソーシャルメディアの普及が重要な役割を果たしている可能性があります。これにより、情報の受け取り方や思考が変わり、特に無党派層の態度が影響を受けると言われています。

最後に

今後の情勢に注目が集まりますが、実際の投票行動が如何に変わるかは予測が難しいところです。そのため、引き続き最新の情報に注意を払い、投票先を決めることが重要です。


関係するページへのリンク:

この情報が選挙についての理解を深める一助となれば幸いです。

  • キーワード: 自民党離れ

自民党 をAmazonで探す
公明党 をAmazonで探す
立憲民主党 をAmazonで探す



※以下、出典元
▶ 元記事を読む

Views: 0

「原幹恵、さんま御殿で突然結婚!」

原幹恵が結婚を発表

2025年7月15日、俳優の原幹恵(38)が自身のインスタグラムを更新し、同日に放送された日本テレビ系バラエティー『踊る!さんま御殿!!』でサプライズ結婚発表を行いました。彼女は、インスタグラムでも改めてその喜びを伝えています。

結婚のメッセージ

原は、インスタグラムに笑顔の写真を添え、「私事で恐縮ですが、このたび結婚いたしました。この節目を、こうして皆さまに直接ご報告できることを心から嬉しく思います。これまで、応援してくださる皆さまのおかげで、日々の仕事に向き合い続けることができました。その支えに改めて感謝の気持ちでいっぱいです」とコメントしました。

原幹恵

原幹恵のプロフィール

原幹恵は1987年7月3日生まれ、新潟県出身です。2003年に「第9回全日本国民的美少女コンテスト」のグラビア賞を受賞し、芸能界にデビュー。その後、「日テレジェニック2006」にも選出され、ドラマ『キューティーハニー THE LIVE』の主演を務めるなど、幅広い活動をしてきました。最近2025年3月には、芸能事務所「Viivo」に所属することを発表し、ビューティアドバイザーとしても活動予定です。

今後の活動

原は、「これからも変わらず、自分らしく頑張っていきたいと思います。今後ともよろしくお願いいたします」とメッセージを締めくくり、ファンへの感謝の気持ちを表明しました。彼女の新たなスタートに、多くのファンが温かい祝福を送っています。

🧠 編集部より:
俳優の原幹恵さんが結婚を発表した件について、少し補足します。 ### 背景 原幹恵さんは1987年生まれで、新潟県出身。2003年に「第9回全日本国民的美少女コンテスト」でグラビア賞を受賞し、芸能界にデビューしました。「日テレジェニック2006」の選抜メンバーとして活躍し、以降はドラマや映画、舞台などに多数出演しています。 ### 豆知識 芸能界では、結婚発表がメディアやファンにとって大きなニュースです。特に、インスタグラムを通じて結婚を報告することは、個人的な感情を直接ファンに伝える良い手段とされています。これは、ファンとの距離を縮める一環とも言えるでしょう。また、原さんは、ダイエットやビューティー分野でも資格を持っており、今後はビューティアドバイザーとしての活動も予定しています。 ### インスタグラムの投稿内容 原さんは、投稿の中で「この節目を、皆様に直接ご報告できることを心から嬉しく思います」と感謝の気持ちを表し、今後も変わらず頑張りたいと意気込みを語っています。このように、結婚発表には、感謝の気持ちと未来に向けた抱負が込められています。 彼女の今後の活動にも期待が寄せられていますね!


  • キーワード: 結婚発表

原幹恵 をAmazonで探す ダイエット&ビューティースペシャリスト をAmazonで探す バストセラピストマスター をAmazonで探す

※以下、出典元 ▶ 元記事を読む

Views: 0