【実例解説】GitHub ActionsでAIを自走させる!スライド自動生成から動画化〜高崎翔太氏と探る自動化の未来〜

video thumbnail for 'GitHub Actionsで“自走するAIワークフロー”を作る GPTs研究会 朝LIVE2025年11月12日(水)朝6:30〜'

最新AI情報満載!毎日無料朝LIVE実施中!GPTs研究会(https://www.facebook.com/groups/gptslabo
朝LIVEブログをメルマガで毎日お届け!AI氣道.jp無料メルマガ(https://ai-kidou.jp/

おはようございます、ひろくんです。

2025年11月12日(水)のGPTs研究会 朝LIVEでは、if塾 塾頭の高崎翔太さんをゲストにお迎えし、「GitHub Actionsで“自走するAIワークフロー”を作る」をテーマにお送りしました。

この記事では、当日の非常にマニアックで実践的なLIVE内容をもとに、AIが人間の手を借りずにコンテンツを生成・更新・配信し続ける「自走型AIワークフロー」の作り方を、実運用の視点で詳しくまとめます。教育現場や個人メディア、スタートアップの情報発信にすぐ使える実践的なノウハウを丁寧に解説しますよ。

朝LIVE 開催概要(2025年11月12日)

テーマ:GitHub Actionsで“自走するAIワークフロー”を作る
──AIが眠っている間に動き続ける仕組みをどう設計するか?

今回のGPTs研究会 朝LIVEでは、if塾の塾頭であり、教育とAI活用の実践者・高崎翔太さんをゲストに迎えました。
高崎さんは、GitHub Actionsをフル活用して、AIが自動でコンテンツを生成・更新・配信する“自走型AIワークフロー”を構築中。教育の現場にもこの仕組みを応用し、「人が手を動かさなくても価値が生まれ続ける未来の学び」を実践しています。
LIVEでは、GitHub Actionsをマニアックに実践している生情報満載でお届け。「毎日動き続けるAIチーム」を作るための構成と考え方を、実際の運用例とともに紹介しました。

登壇者

ゲスト:高崎翔太(if塾 塾頭)
元臨床心理士。株式会社LITALICOで発達支援に携わり、秋田へ移住。ITコンサル・ゲーム開発・高校教諭を経てif塾を設立。現在は「AI×教育×クリエイティブ」を軸に、全国で活動中。子どもがAIと共に働き、学び、成長する新しい学びの場づくりに取り組んでいる。
https://if-juku.net

ホスト:田中啓之(ひろくん)
GPTs研究会ファウンダー/三方よしAI共創コンサルタント。AIと人の共創で“現場が楽になる仕組み”を生み出す主夫社長。分身AIを使い、家庭・仕事・発信を自動化するライフスタイルを実践中。
https://bunshin-ai.com

目次

🔧 全体像:自走するAIワークフローとは何か

自走するAIワークフローとは、AIモデルとクラウドサービス、CI/CDの仕組みを組み合わせて、定期的にデータ取得、コンテンツ生成、変換(スライド・動画・音声)、公開までを自動で回すシステムです。ポイントは「人が寝ている間にも価値を生み続ける」点。私が目指すのは「人が頑張Rらなくても回る仕組み」。分身AIを使って、毎朝6時に最新のコンテンツが配信される仕組みを作るイメージです。

【リライトくんの補足💡】
「自走型AIワークフロー」を料理に例えるなら、「毎朝決まった時間に、冷蔵庫の残り物(データ)をチェックし、最新の健康トレンド(ニュースAPI)を調べて、家族好み(プロンプト)の朝食(コンテンツ)を作り、食卓に並べる(配信する)までを全自動でやってくれる料理ロボット」のようなものです。一度設定すれば、あなたは朝寝ていても大丈夫。これがビジネスや情報発信で動くイメージです。

構成要素の短いリスト

  • データ収集:RSS、ニュースAPI、スクレイピング、Google Drive や GitHub のドキュメント
  • 知識ベース:MarkdownやDBに溜めたナレッジ、外部ファイル(Google Driveなど)
  • 生成部:GPT系APIやノートブックLMで文章・スライド・タグラインを生成
  • 変換部:スライド→動画、テキスト→音声(TTS)、画像生成
  • オーケストレーション:GitHub ActionsやCloud Codeでワークフローをスケジューリング
  • 配信:YouTube、ブログ(WordPress REST API)、SNS自動投稿
  • モニタリング:ログ収集、エラー通知、フィードバックループ
自走するAIワークフローのオープニング画面と登壇者の顔が並ぶスクリーンショット

動画の該当箇所([00:00:31])はこちら

冒頭で「今日のテーマはGitHub Actionsで自走するAIワークフローを作る」という宣言。まずは全体像を固めることが出発点だよ、という僕のスタンスが出ている部分です。

🛠️ GitHub Actionsを選ぶ理由と設計原則

GitHub Actionsを使う利点は、コードとドキュメントが同じリポジトリで完結し、スケジュール(cron)やイベント(push、PR)で動かせる点。マーケットプレイスで既成のActionが大量にあるので、組み合わせて短期間で仕組みを立ち上げられるのが強みです。

【リライトくんの補足💡】
GitHub Actions」は、プログラムの設計図やコードを置く場所(GitHub)にある「自動化された作業台」です。例えば、家事で言えば「月曜の朝9時になったら、洗濯カゴ(データ)をチェックして、洗濯機(生成AI)を回し、乾燥(変換)させて、畳んでタンス(配信先)にしまう」という一連の作業を自動でやってくれるイメージです。この作業の流れを「ワークフロー」と呼びます。

よく似た言葉に「CI/CD」がありますが、これは「こまめにチェック(CI=継続的インテグレーション)して、OKならすぐにお店に出す(CD=継続的デリバリー)」という流れを自動化する考え方で、GitHub Actionsはそれを実現する具体的な道具の一つです。

設計時に意識すべき3つの原則

  1. 分離(Separation of Concerns):収集・生成・変換・配信を明確に分ける。障害時に切り分けやすくするため。
  2. 冪等性(Idempotency):何度実行しても同じ結果が出るように。特に動画生成や公開処理で重要。
  3. 観測性(Observability):ログ、ステータス、エラー通知を設ける。Slackやメールの通知は最低限つける。

【リライトくんの補足💡】
特に大事なのが2番目の「冪等性(べきとうせい)」です。これは「何度やっても同じ結果になる」という意味です。例えば、料理レシピで「塩をひとつまみ加える」という指示は、実行するたびに塩辛くなりますよね(冪等性がない)。一方で、「塩分濃度を1%にする」という指示なら、何度実行しても(すでに1%なら何もせず、足りなければ加え)、必ず塩分濃度1%という同じ結果になります(冪等性がある)。自動化システムでは、この「冪等性」を担保する設計がとても重要です。

スライドとターミナル表示が横並びになったウェビナーのスクリーンショット(ワークフロー分割の解説)

動画の該当箇所([00:03:13])はこちら

ここではGitHub Actionsの基本概念と「ワークフローを小さなステップに分割する」話が出ます。実運用ではこの考え方が失敗を防ぎます。

📄 実例:スライド自動生成→動画化→公開のワークフロー

現場で一番汎用的に使えるパターンが「記事やニュースをもとにスライドを自動生成し、それを元に動画を作ってYouTubeにアップする」流れ。ここを具体的に分解します。

ステップ別の詳細

  • ステップ1:情報収集
    RSSやニュースAPI、GitHubのMarkdownファイル、Google Driveのドキュメントを取得。取得したデータはリポジトリ内のdataフォルダや外部ストレージに格納。
  • ステップ2:要約と構成生成
    GPT系に記事を渡して、スライド構成(タイトル、箇条書き、キー画像のプロンプト)を生成。出力はMarkdownやJSONで保存。
  • ステップ3:画像生成とTTS
    各スライドの画像を画像生成APIで作り、テキストはTTS(Text to Speech=音声合成)で音声化。音声は動画合成用にwav/mp3で出力。
  • ステップ4:動画合成
    RemotionFFmpeg(動画をプログラムで扱うためのツール)を使ってスライド、音声、アニメーションを組み合わせて動画にする。これをGitHub Actionsのジョブで実行。
  • ステップ5:公開と投稿
    生成した動画をYouTubeにアップロードし、動画URLをWordPress APIに送りブログを自動で更新。SNS連携も自動投稿。
  • ステップ6:モニタリングとフィードバック
    公開後の視聴データやコメントを収集し、改善に使う。次のワークフローに反映する。
GitHub Actionsの「Generate Presentation」ワークフロー画面を中心に、左に配信のビデオサムネイルがあるスクリーンショット。フローの概要が確認できる。

動画の該当箇所([00:05:26])はこちら

「Create Video」ボタンでスライド→動画化までの流れを示した場面。ここで全体のパイプライン像が見えると設計がかなり楽になります。

⚙️ 技術選定:Cloud Code vs CLI vs GitHub Actions

動画中では「Gemini CLIが途中で止まる」「Cloud Codeは安定して高レベルで扱いやすい」という話がありました。実際に私が勧めるのは次の使い分けです。

使い分けガイド

  • 小回りとデバッグが必要なとき:ローカルCLIで試す。Gemini CLIのようにローカルでの高速プロトタイプは有効。ただしスケールや並列実行が必要になったら注意。
  • 安定稼働と監視が重要なとき:Cloud Code(マネージド環境)。ログやデプロイが楽で運用負荷が小さい。
  • コード管理と週次/日次バッチが必要なとき:GitHub Actions。リポジトリに近い場所でCIとして回すのが便利。

動画の該当箇所([00:10:21])はこちら

ここでCloud Codeの利点と、CLIの限界が語られます。運用の安定性を優先するならCloud CodeやGitHub Actionsの利用が鉄板だよね。

💸 コスト設計:スライド動画は安くつくれるのか?

「1スライド60円」「テキスト生成は0.9円程度」といった話が出ていました。これはあくまで参考値ですが、コスト設計のポイントは以下。

コスト最適化のポイント

  1. テキスト生成は安い:テキストベースの生成はコスト効率が良い。スライドの文言や要約は積極的に自動化。
  2. 画像と音声がコストの主因:高品質な画像生成やTTSは頻度と品質に応じてコストが跳ねる。重要スライドのみ高品質生成にするなどの工夫を。
  3. 分散処理で効率化:動画合成など時間がかかる処理は、短時間に集中してクラウドで実行することで時間課金を最小化。
  4. キャッシュの利用:一度生成したアセットはGCS/S3やGit LFSに保存して再利用する。無駄な再生成を防ぐ。

動画の該当箇所([00:13:20])はこちら

ここでコストの大きな要因が語られています。特に画像生成やTTSの回数は意識的に設計しないとコストが跳ねるので注意です。

📦 実運用Tips:WordPressとAPI連携でブログを自動更新

私が実際にやっているパターンは、生成した動画URLをWordPressのREST APIにポストして自動で記事を作る方法。コメント機能やAIによるコメント生成も組み合わせれば、ブログが「動く」ようになります。

【リライトくんの補足💡】
WordPress REST API」を例えるなら、WordPressというブログシステム(お店)の「ドライブスルーやテイクアウトの専用窓口」です。通常、人はお店の正面玄関(管理画面)から入って記事を書きますが、この窓口(API)を使えば、GitHub Actionsのような外部の自動化プログラムが「この記事、載せといて!」と注文(データ投稿)できるようになります。

ステップと注意点

  • 投稿テンプレートを用意:タイトル、抜粋、アイキャッチ、YouTube埋め込み用のメタデータをテンプレート化。
  • 認証トークンの管理:GitHub SecretsやVaultを使ってWordPressの認証情報(お店の合鍵)を安全に保持。
  • スケールを考慮:大量投稿時はWordPress側のAPIレート制限(注文の受付上限)やキャッシュ戦略を検討。
WordPressの記事ページが表示された画面のスクリーンショットと左側に小さくオンラインミーティングのサムネイル

動画の該当箇所([00:16:02])はこちら

WordPressとREST APIを繋ぐ実例の解説シーン。記事化とコメント管理まで自動化するフローのヒントが詰まっています。

🧠 フィードバックループと自己改善(自走の心臓部)

単にコンテンツを生成して公開するだけでは不十分。公開後のデータを回収してモデルやプロンプト、テンプレートを改善する「フィードバックループ」を組み込むことで、真に自走するシステムになります。

【リライトくんの補足💡】
これは、料理ロボットが「出した料理の食べ残し(視聴維持率)や、お客さんの感想(コメント)を分析して、自動で次の日のレシピを改良する」ようなものです。これがあるから、AIはどんどん賢くなり、人間の手間が減っていきます。

実装アイデア

  • 公開後にYouTubeの再生数・コメント数・エンゲージメントを自動取得し、スコア付け。
  • スコアの低いコンテンツの共通点を抽出し、プロンプト改良タスクを自動で生成。
  • コメントをAIが要約して次回コンテンツのネタにする。
自走するAIワークフローの運用イメージを説明するオンライン登壇のスクリーンショット。スライド背景とターミナル画面が見える。

動画の該当箇所([00:20:26])はこちら

「毎日6時にニュースを見て、動画が完成したらブログになる」流れの話。ここが自走ワークフローの繰り返しループのイメージです。

🔍 デバッグと運用でよくあるつまずきポイント

実運用でよくある問題と対処法をまとめます。私も何度もハマったので忖度なしで伝えますよ。

よくある問題と対応

  • Actionが途中で止まる/タイムアウト
    → ジョブを短く分割し、ステップごとにチェックポイントを作る。長時間処理はクラウドバッチへ移行。
  • データの不整合(重複公開など)
    → アイテムごとにユニークIDを付け、公開済みかをDBで管理する(冪等性の確保)。
  • APIやモデルのバージョン変更で動かなくなる
    → バージョン管理と定期的なスモークテスト(簡単な動作確認)を入れる。
  • 品質が安定しない(生成物のばらつき)
    → プロンプトのテンプレート化、温度やパラメータの固定化、サンプルベースのフィルタリングをする。

動画の該当箇所([00:21:52])はこちら

Live previewやブラウザでの確認の重要性が語られています。ライブプレビューがあると開発スピードがかなり上がるよ。

🧩 オープンソースで加速する:Marketplaceと既存Actionの活用

GitHub Marketplaceには便利なActionが大量にあります。0から作るより既製品を組み合わせて早くローンチし、後から改善していくのが合理的です。

【リライトくんの補足💡】
GitHub Marketplace」は、料理ロボット(GitHub Actions)で使える「便利な調理器具や半調理済みの食材が売っているお店」です。「YouTubeにアップする器具」や「Slackに通知する食材キット」などが揃っているので、これらを買ってきて組み合わせるだけで、すぐに立派な料理(ワークフロー)が完成します。

使うべきActionの例

  • actions/checkout (作業台にコードを広げる)
  • actions/upload-artifact / download-artifact(調理途中の食材を一時保管する)
  • actions/cache(よく使う調味料をキャッシュする)
  • サードパーティのYouTubeアップロードActionやWordPress投稿Action
Qiitaに掲載されたGemini RAG/File Searchの解説記事のスクリーンショット、左に配信者の顔入りの画面表示

動画の該当箇所([00:23:19])はこちら

Geminiのファイル検索ツールやGitHub上のmarkdown運用の話。オープンソースを活用することで開発スピードは劇的に上がります。

💻 ローカル開発とクラウド実行のバランス

ローカルでプロトタイプしてからクラウドに移すパターンが合理的。ローカルは高速なフィードバック、クラウドはスケールと安定動作を担保します。

【リライトくんの補足💡】
ローカル開発は「自宅のキッチンで新しいレシピを試作する」こと。手軽に何度も試せます。クラウド実行は「完成したレシピを工場のライン(クラウド)に乗せて大量生産する」こと。安定してたくさん作れます。まずはキッチンで味見してから、工場に発注するのが賢明ですよね。

実務的な流れ

  1. ローカルでCLIを回してプロンプトや合成処理を固める
  2. 短時間のバッチ処理をGitHub Actionsに移す
  3. 長時間・GPU依存の処理はCloud Batch / Cloud Functionsへ移行
ビデオ会議のスクリーンショット。左に資料背景の発表者、右に端末ログを背負った発表者の顔が並ぶ画面。

動画の該当箇所([00:27:47])はこちら

ローカル(32GB M4など)での実行は便利だけど、負荷や同時アクセスを考えるとクラウドが安心、という話です。

🎯 実際に作るためのチェックリスト(私の推奨テンプレート)

ここに書いてある順でやれば、まずは「1週間自走するAIチーム」を作れるはず。私のワークショップでもこの順を使ってます。

最小実行可能プロダクト(MVP)の作り方

  1. 要件定義:何を毎日届けたいか?(例:AIニュース10本をスライド化→3分動画)
  2. データ収集パイプライン:RSS → JSON化 → /data 配下
  3. 生成プロンプトのテンプレ化:テンプレートと期待出力のサンプルを作る
  4. GitHub Actionsワークフロー作成:スケジュール→収集→生成→変換→公開
  5. 初回テストと報告:Slack通知、失敗時はPRで止める設定
  6. 観測と改善ループ:公開後のKPIを自動取得し、週次で改善タスクを生成
Finderで開いたWorkFlow_originフォルダのスクリーンショット(package.json、README、srcなどが見える)

動画の該当箇所([00:30:12])はこちら

GitHub Actionのローカルファイル操作やコンソール実行の話。最初はローカルで動くことを確認すると安心だよ。

📣 ワークショップ案内と次の一手

私たちはこの流れをワークショップに落とし込み、ハンズオンで「自分の分身AIが朝動く」まで持っていきます。興味あるなら、まずは次のチェックリストから始めよう。

ワークショップで学べること

  • GitHub Actionsの基本と実践的ワークフロー設計
  • GPT系APIを安全に運用するためのプロンプト設計
  • 動画合成(Remotion/FFmpeg)とTTSの組み込み
  • WordPressやYouTube連携の自動化
ワークショップ呼びかけ時の登壇者とスライド、ターミナル表示が一緒に映る画面のキャプチャ

動画の該当箇所([00:33:28])はこちら

「試してみてください」というラストの呼びかけ。この一歩が自走化への分岐点になりますよね。

❗ よくある質問(FAQ)

GitHub Actionsだけで全てを完結できますか?

短期的なパイプラインや軽量処理なら可能です。ただしGPUが必要な重たい画像生成・動画レンダリングは外部クラウドのバッチ処理やManagedサービスに任せた方が安定します。長時間処理はActionsのタイムアウトに注意。

生成コンテンツの品質がばらつく時の対処法は?

プロンプトのテンプレート化、温度やトップPなどのパラメータ固定、サンプル出力でのフィルタリングを組み合わせます。さらにフィードバックループで公開後のデータを学習に使うと安定化します。

運用コストを抑えるコツは?

画像や音声の再生成を避けるためのキャッシュ、必要な部分だけ高品質生成にすること、バッチ処理の時間帯を低価格帯にすること、そしてアセットの再利用が有効です。

セキュリティ対策で必須の項目は?

APIキーや認証情報はGitHub SecretsやVaultで管理。外部APIコールは最小権限にし、公開コンテンツの自動投稿はレート制限や誤投稿の回避ロジックを入れること。

どれくらいの頻度で自走させるのが現実的ですか?

まずは日次運用がおすすめ。毎朝6時に最新のものが出るようにスケジュールすれば、十分実用的です。週次〜月次は素材収集量によるので柔軟に。

失敗したときの人の介入はどう設計すべきですか?

失敗検知で該当ジョブを停止し、Slackやメールで通知。必要なら自動でPR(プルリクエスト=修正提案)を作ってレビュープロセスを起動するフローを用意すると復旧が速いです。

🌱 最後に — 私の哲学と実践のすすめ

「あなたが頑張Rらなくても回る仕組み」を分身AIで作る。失敗は宝、改善は習慣。自走ワークフローは一朝一夕で完成しないけど、一度回り始めれば大きな資産になります。

私は134kgから50kgのダイエットに成功した経験や、事業の逆境を乗り越えた経験から言います。仕組みを作ることは、身体を鍛えるのと同じで最初が一番しんどい。でも仕組みが動き始めると、自由な時間と継続的な成果が手に入ります。

公園でギターを弾き笑顔の女性のスクリーンショット(クロージング)

動画の該当箇所([00:43:00])はこちら

終盤の希望に満ちたメッセージ。AIと共に未来を創るというビジョンは、実装のモチベーションになりますよね。

📩 アクションプラン(今日からできる3つのこと)

  1. リポジトリを作って簡単なGitHub Actionsのcronジョブを1つ作る(ニュース取得→JSON化)
  2. 生成のテンプレート(スライド構成)を1つ作ってAPIでテスト
  3. 生成物の公開先(YouTube or WordPress)のAPI連携を試してみる

最初は小さく。動くものを早く作って、改善を回していこう。困ったら僕のワークショップで一緒に作るのもありだよ。

📌 参考スクリーンショット(ピンポイントで押さえる場面)

以下は記事内で触れた重要なポイントを示すスクリーンショット候補です。各キャプチャは動画の該当秒数リンクを付けているので、該当シーンに飛んで確認してください。

配信のオープニング画面。左に『社長無人化計画』のタイトル背景とホスト、右に共同登壇者の画面が並ぶスクリーンショット。

動画: [00:00:31] — オープニングと今回のテーマ発表

左右分割のビデオ会議画面のスクリーンショット。左に説明用スライド風背景、右にターミナルと参加者が表示される構成。

動画: [00:03:13] — GitHub Actionsの概要説明シーン

GitHub Actionsの「Generate Presentation」ワークフローを示すスクリーンショット。ワークフロー名や実行項目が中央に見える。

動画: [00:05:26] — スライド自動生成から動画作成までのフロー説明

動画: [00:08:02] — Remotionやプログラム的な動画合成についての言及

プレゼンのスライド「はじめに」と右側に未来都市のイラスト、左に登壇者の小ウィンドウがある画面のスクリーンショット

動画: [00:10:21] — Cloud CodeとCLIの比較講義

オンライン対談のスクリーンショット。左にプレゼン背景の参加者、右にターミナル表示の参加者。

動画: [00:11:42] — スライド多言語化の話

動画: [00:13:20] — テキスト生成と画像/TTSコストの概算

右側にWordPressの記事プレビュー、左下に小さな配信者映像が入ったスクリーンショット

動画: [00:16:02] — WordPressサイトとREST API連携の実例

モーニングライブで自走ワークフローについて話す二人の登壇者と端末の出力が見えるスクリーンショット

動画: [00:20:26] — 毎朝6時に更新する運用イメージ

画面のスクリーンショット。左に小さな登壇者映像、中央にコードエディタ、右に明るいブラウザのプレビューが表示されている。

動画: [00:21:52] — Live previewやUIの話

Qiitaの記事ページのスクリーンショット(Gemini RAG/Gemini APIのFile Search Toolの説明が表示されたページ)

動画: [00:23:19] — Geminiファイル検索やMarkdown運用の言及

分割画面のライブ配信スクリーンショット。右側にターミナルのコード表示があり、ローカル環境の説明に合うビジュアル。

動画: [00:25:07] — Kamui OSやローカル/グラフィカル環境の話

Zoom風の画面。右側にターミナル出力とコードが見える背景、左右に発表者が表示されたスクリーンショット。

動画: [00:27:47] — ローカル実行とクラウド実行のバランス

WorkFlow_originフォルダを表示したFinderウィンドウのクリーンなスクリーンショット。スクリプトやpackage.jsonが確認できる

動画: [00:30:12] — ローカルでのコンソール操作とファイル管理

ワークショップ呼びかけの画面キャプチャ、デモ用スライドと発表者のビデオウィンドウ

動画: [00:33:28] — ワークショップ提案と次回予告

配信画面のワイドショット。左に『社長無人化計画』のタイトルを背負ったスピーカー、右にもう一人とターミナル表示が見える。

動画: [00:38:47] — マネタイズや自動化の将来像

動画: [00:43:00] — クロージングの希望に満ちたメッセージ

✍️ まとめと私からのメッセージ

自走するAIワークフローは特別な力を持っているわけではなく、正しい分割、堅牢なパイプライン、そして継続的な改善がすべてです。最初は小さく始めて、日次で回す運用に落とし込めば、あなたの時間が増え、チームの生産性が上がり、生活の質も改善します。

私のモットーは「分身AIで社長無人化計画」。まずは一つのワークフローを動かしてみてください。何かあればDMで相談してくれて良いし、一緒にワークショップで作ってもいいですよ。ではまた、朝の6時に動くあなたのAIチームをつくりましょう。ひろくんでした。

GPTs研究会はこちら!

  .

無料!AI最新情報コミュニティ

         今すぐGPTs研究会をチェック!

#GPTs研究会 #GitHubActions #if塾 #AI教育 #AI自動化 #分身AI #AI氣道

この記事が「自走型AI」への第一歩となれば嬉しいです。
最新AI情報満載!毎日無料朝LIVE実施中!GPTs研究会(https://www.facebook.com/groups/gptslabo
朝LIVEブログをメルマガで毎日お届け!AI氣道.jp無料メルマガ(https://ai-kidou.jp/

上部へスクロール