tyoshikawa1106のブログ

- Force.com Developer Blog -

SFDC:CodexでHeroku × Salesforce API連携を試してみました

Codex開発でHerokuアプリのSalesforce API を実行するアプリの作成を試してみました。この記事の続き。

GitHub リポジトリ

Codexにやりたいことを指示する形で実装できました。

デザインに使ったCSSフレームワーク

Salesforce Lightning Design System v1 をつかってデザインをSalesforceのLightning Experienceに寄せました。


最新のLightning Design System は v2 が出ています。 v1 のように専用のCSSがあるのかと最初勘違いしてましたが、Styling HooksでCSS変数を変える形で v1 から v2にアップデートできるようです。今回は v1 のまま進めました。

ログイン画面

外部クライアントアプリケーションでコンシューマ鍵 (client id)と秘密 (client secret)を発行して、HerokuアプリとSalesforce環境を接続しています。


接続ボタンをクリックすると認証画面が表示されるので許可します。

ホームタブの画面

Herokuアプリのトップ画面。


取引先タブの画面

レコード一覧

新規ボタン


レコード参照


レコード編集


レコード削除

取引先責任者タブの画面

取引先と同じように参照、編集、削除が動きます。

連携タブの画面

Integration ライセンスユーザーの連携処理を動かす機能。外部クライアントアプリケーション側で認証設定しているので都度のログインは不要なユーザー。


ごみ箱タブの画面

ALL ROWSを使う形でクエリを実行して一覧を取得。


チェックをつけて復元。


活動 (行動 & ToDo)

活動タイムライン


活動作成ドック

日時の入力

参考項目の入力

エラーチェック


ユーティティバー


開いている画面のReactコンポーネントを表示。(動的に取得ではなく、画面URLなどから固定表示)

ヘッダーアクション


Salesforce APIとLightning Deisgn Systemを使って、Salesforceと同じような画面のHerokuアプリを作成できました。Salesforce APIをつかったデータの参照、作成、編集、削除といった処理を実装するには、Salesforceのプラットフォーム自体の理解がないと開発できないですがCodexはSalesforceに関する紹鴎を正しく理解して必要な実装を進めてくれました。


なかなかうまくいかなかったところとしては、UI部分についてです。右寄せ、左寄せ、余白、アイコン表示など、画面表示まわりについては正しく実装状況を識別してくれず、修正指示が必要になりました。ただ、画面のスクリーンショットを取って添付することで状況を理解して次のアクションを取ってくれたので、テキストでの指示だけじゃなく画像ファイルなどと組み合わせて指示すれば良いみたいです。

SFDC:Agentforce World Tour Tokyo Day 2

2026年6月10日のAgentforce World Tour Tokyo Day 2です。

基調講演 (Agentorce と切り拓く管理者・開発者の新境地)

Day 2は開発者向けセッションが多くなります。まずは基調講演セッションを見に行きました。


Salesforce x Informatica

次にみたのがInformaticaのセッションです。Day 1でInformaticaのブースに行きましたがより詳細な話が聞けました。

Data360最新ロードマップ

Data 360 (旧Data Cloud)のロードマップ話です。


非構造化データ活用

こちらもData 360関係のセッションです。

Agentforce Marketing ブース

旧Marketing Cloudのブースです。AIチャットのヒアリング結果に基づく動的Webフォームの構築ができること、ExperienceCloudのサイトとは別サイトになることを確認できました。


また、マーケティングに対してメールの返信は基本受け付けないと思いますが、Agentforce Marketing ではそうした返信メールをAgentforceエージェントが確認してコメント返信してくれる機能を構築できるようです。


そうしたやりとりはメッセージセッションレコードとしてSalesforce上に登録されるようになっています。そのやりとりを起点にエージェントから対応を引き継いて顧客対応するといった使い方ができるみたいです。


Agentforce Commerce ブース

ECサイトを構築できる製品のブースでも話を聞けました。ECサイトといえばBtoC向けのサイトというイメージがあったのですが、BtoB向けのECサイトも構築できます。

ログインユーザーは各企業の顧客となりますが、例えば企業ごとにサイトの表示内容を変更したり、制御を調整したりすることが可能です。Webサイトの構築だけではなく、見積書、注文といった仕組みが構築できます。(CommerceのログインユーザーはExperienceCloudのログインユーザーとは別になります。)

登録されたデータはもちろんSalesforce上に保存されます。SalesやService側との連携なども可能です。


Agentforce Script ブース

Agentforce Scirptブースでは、新しいAgentforceスタジオの機能について話を聞けました。

Agentforceエージェントは最初設定画面の方で必要な設定をしていく形でしたが、アプリケーション側で設定する形に変わっています。単に表示画面が変わるのではなく、作成されるエージェントの種類も異なります。Agentforceスタジオで作成した方が新しい機能が追加される形になりますので、旧方式で作成したものは移行していく形となります。移行対象はリストの中にアイコン表示されるみたいです。


ブース名になっているAgentforce Scriptはこちらの設定です。今までは画面操作でのみ設定ができましたが、プログラミングのような形での設定が可能になりました。

設定画面の中のエージェント相談は引き続き可能です。

新しいエージェント設定では用語も変更されています。トピックというメニューはサブエージェントに変わりました。

Security ブース

SecurityブースではSalesforce Shieldの話を聞くことができました。左側がShieldの契約の中に含まれる機能で右側はまた別の契約の機能です。Shieldの中の機能も個別に契約できますがまとめて契約した方がディスカッションなどの恩恵が得られる形となっているようです。


イベントモニタリングは監査用途のログ分析ができる機能です。古いAPIが使われていないか、設定変更履歴の作業者は誰かをダッシュボード形式で確認することができます。

項目監査履歴は、標準デフォルトの項目変更履歴の拡張的な感じです。デフォルトでは20項目が追跡対象ですが、60項目まで増やすことができます。そして、Spring'26のアップデートで200まで追跡可能となりました。追跡数を増やしてもデータストレージの圧迫などに繋がらないので重要な項目で上限の問題で諦めていたものは対象に追加できます。項目変更履歴のデータはあくまで監査用途です。24か月の保持期間のとなっているので注意が必要です。(保持期間を増やす製品もあったと思います)


プラットフォーム暗号化は、データベースと項目ベースで暗号化を行うことができる仕組みです。ユーザーに表示される値は復号化されるので今までどおりに表示されます。裏側の保存データの暗号化によるセキュリティ強化です。とにかく暗号化すれば安心という使い方ではなく社内ポリシーで必要な場合に検討する使い方です。(クレジットカード番号やマイナンバー、医療情報ちうった機微情報を扱うシステムで必要になります。)

Data Defectは、Salesforce上に保管すべき機微情報が含まれていないかなどの調査ができる仕組みです。過去のSalesforceイベントでの事例として、ケース問い合わせ対応中にお客様からのメールにクレジットカード番号が含まれていたなどそうした情報を見つけることができます。

Agentforce Labs

Agentforce LabsブースはAgentforceの機能について1on1で相談できるブースです。事前予約は埋まっていましたが当日予約も受け付けていたので行ってみました。


ちなみにAgentforce Labsという名称で、サイト(ツール?)もあります。最初このツールの話が聞けるブースかと少し勘違いしました。


新しいAgentforce スタジオの設定まわりについて教えてもらいました。昨年12月時点では設定メニューのエージェント作成のやり方がTrailheadなどでも案内されていましたが、もう仕組みが変わったことでまた一から機能確認する必要がありました。このブースで話を聞いて全体像が確認できて今後の学習が進めやすくなったと思います。


既存のAgentforceエージェントの設定を新しいAgentforceスタジオに移行する操作まわりを見せてもらいました。

移行ツールはサポートツール的なものでそのままでは動かない場合もあります。そうした場合はエラーメッセージを見ながら原因調査して対処していきます。このときスクリプト側での確認がスムーズのようです。

Lightning MiniHack Live

一番最後のセッションはMiniHack Liveを見に行きました。こうしたイベントで開発者の設定作業を見る機会はあまりないので面白かったし参考になりました。

まとめ

Agentforce World Tour Tokyo Day 2では以上のセッションを見に行けました。AWTTサイトではセッションのアーカイブ配信もしているみたいなので、今度見に行けなかったセッションの確認はしようと思います。

SFDC:Agentforce World Tour Tokyo Day 1 - セッションとブース

Agentforce World Tour Tokyo Day 1 の記事の続き。基調講演のあとのセッションとブースをまわったときの話です。

Platform ブース

イベントに行くとSalesforce製品のブースが出ています。こちらで新機能や気になる昨日について話を聞くことができます。話が聞けるタイミングが合ったブースから回ってみました。PlatformブースではVibeコーディングに関する話を聞くことができました。


Agentforce VibsはAIコーディングを行うための仕組みです。Apex、LWCといった開発を生成AIと一緒に進めることができます。


開発はVS Codeでやることが多いと思いますが開発者コンソールの進化版的な統合開発環境(IDE)- Agentforce Vibes IDEも用意されています。


CodexやClaude Codeを使った開発のSalesforce版という形です。生成AIのモデルはGPTやClaudeなどの各モデルを使って行いますが、Agentforce Vibsを使う背景としてはEinstein TrustLayerの仕組みの中で動くという点になるようです。


Salesforce Help


Einstein Trust Layer | セールスフォース・ジャパン


Agentforce Vibsを利用するにはライセンスが必要です。AgentforceのFlexライセンスで利用回数に応じた課金モデルのプランで利用ができます。ただ、本格的に開発するときに利用回数に応じたでは予算を超えてしまう懸念が大きいです。利用上限の無い開発者用のライセンスが別途あり、そちらの導入を検討するのが良いと思います。ただ、上限が無いということで料金もかなり上がる感じになるかと思います。


Agentforceの価格はこちらのサイトで確認できました。


ただ、開発者用ライセンスというような表示はなかったので、正確な情報は問い合わせして確認するしかなさそうです。アドオンとして紹介されている左側のやつかもしれません。

やまや ブース

Webサイト上にあるAIチャットのやりとりで利用者の求めることをヒアリングし、Webサイトを動的に切り替える仕組みのデモをみることができました。


Agentforce Marketing (旧Marketing Cloud)の仕組みで構築されているものだと思います。

エージェント型マーケティングプラットフォーム:次世代のMarketing Cloud | セールスフォース・ジャパン

Informatica ブース

2026年3月ごろにSalesforce製品の一つになったInformaticaのブースがあったので行ってみました。様々なシステムのデータ統合を実現するための製品です。


最初、Data 360と役割が同じなのかと思ったのですが、それぞれ別の役割を持っていて使い分ける形になっています。違いについてはPiperに質問したらわかりやすくまとめてくれました。

Agentforce ブース

Cowokerのデモを見ることができました。まだベータ版の機能で既存の右上アイコンで呼び出すAgentforceエージェントとは別の仕組みとなっています。

社内のOffiece365やGoogleと連携することでSharePoint / GoogleDrive上にあるPDFファイルをRAGとして回答に使ったりできます。(Data 360の契約も必要)

ルームセッション


Agentforce ブース

Agentforce Service ブース

問い合わせ対応まわりの昨日のデモを確認。Agentforceエージェントがチャット対応をしてくれます。サービスエージェントで作られたエージェントです。


サービスコマンドセンターという画面があります。ここでAgentforceエージェントの対応状況などを確認できます。特定の条件に一致するものはフラグをつけることが可能です。


現在も使われている機能ですが顧客はExperience Cloudサイトに埋め込まれたチャットで相談していきます。チャットログはSalesforceに記録されるので、このやりとりを見て、サポート担当者はAIエージェントから対応を引き継ぎます。


問い合わせ対応完了後に今後のナレッジとして扱うべき場合は、ナレッジ登録ボタンから登録可能です。AIがまとめた対応サマリをベースにできるのでスムーズな登録が可能です。

Slackbot ブース

Slackbot ブースでは、Slackの画面で実現できる業務効率化の話を聞けました。

画像からテキストを識別してデータ更新するといった操作が可能です。AIにテキスト化してもらい、けっかを確認、認識誤りがあったら修正して登録を依頼という使い方です。

条件に一致するデータを探してもらう使い方もできます。

過去の会話ログも残るのであのときどうしたっけ的なものを振り返りできます。

データの判断ができるので日報作成といった使い方もできます。Slack上にあるCanvasの仕組みでドキュメント作成が可能です。

MTG相手の予定を確認して予定の登録をAI経由で行う使い方もできるそうです。これはGoogleカレンダーとSlackを連携させる設定を最初に行っているとのことです。Salesforce側のGoogle連携とは別の設定ということでした。

業界ブース

Salesforceには業種別に特化したIndustry Cloudという製品があります。自動車や通信、保険といったブースが今回のイベントにありました。


Salesforceの業種別製品・ソリューション一覧 | セールスフォース・ジャパン


その中に人材サービスというブースがありました。最初、Industry Cloudの対象業種が増えたのかなと思ったのですが、こちらは扱いとしてはIndustry Cloudではなくデモアプリ的な形として用意されているものとのことです。

活動データの話の中でやはり出てきたという感じでEinstein活動インサイトの機能がありました。ZoomやTeamsといったWeb会話の活動を記録する仕組みです。

連携設定することでビデオ録画の結果とその情報を元にした文字起こし、タグつけなどの分析が可能となっています。


概要機能で通話の要約を確認できます。

概要は数行でチェックできて便利ですが、要約されすぎという場面のために詳細を確認の機能が用意されていました。これで細かな部分もEinsteinに相談できます。

活動タイムライン上からだと会話を探索というリンクからアクセスできます。

そのほかはカスタマイズ部分、オシャレなグラフなどはLightningページに配置することでレイアウト調整できます。LWC開発やAppExchnageでコンポーネントを用意したら画面表示はノーコードで実現できます。

Salesforce上にデータが揃っていればAIがスクリプトや次のアクションを提案したりしてくれるようになります。こういったことがSalesforceで実現できますというデモとして見せてもらえました。


Agentforce Sales


Trailhead Theater セッション

会場の中にTheaterエリアがあり、ミニセッションをみることができます。Salesforceイベントのアーカイブ動画では確か録画公開されていなかったと思うので会場にいったら見ておくと良いセッションとなっています。


Agentforce World Tour Tokyo Day 1はこんな感じでした。

SFDC:Agentforce World Tour Tokyo Day 1 - 基調講演

2026年の6月9日のAgentforce World Tour Tokyo (1日目)の話。

基調講演

ここ最近の製品紹介。2026年はSlack bot。


AIエージェントの重要性の話。


Salesforce社の開発チームでもコーディングエージェントを使って開発を行っているそうです。


基調講演ではインサイドセールスAIエージェント「Piper(パイパー)」が発表されました。


音声でやりとりできるエージェントで、Salesforce社のWebサイトで実際に体験することができます。


AIエージェント用にAppExchnageもアップデートされました。これで開発に時間をかけず時に必要なアプリを探して購入したりできるようになっています。


Salesforceを使ってAIエージェントをどのように活用できるか、そうした話を聞くことができました。


Salesforceの中に埋め込むAIチャット機能「Agentforce Coworker」も新しく登場しました。自然言語でAIエージェントと会話して必要な情報にアクセスできるようになります。SalesforceにあったAgentforce エージェントの機能とはまた別の仕組みとなるようです。(Agentforce Coworkerと設定で作成したAgentforceエージェントを紐付けて機能拡張できるようなイメージ)


ちなみにこういう新機能の気になったところもPiperに相談できました。音声で会話しながら相談できます。


チャットでのやりとりもできるのですが、その場合、回答の出力結果が文字起こし系ではなく生成されたけっかになっていました。


Salesforceから発表されたAIエージェントの話の中で「Headless 360」という単語が登場しました。Coworkerのような機能をSlackなど別のシステム上に構築できる仕組みを用意したという話です。


Agentforceビルダーも新しくなりました。Agentforceエージェントを設定するための画面ですが、UIが見やすくなって設定作業がやりやすくなっているみたいです。設定メニューの方ではなく、アプリケーションランチャーのAgentforceスタジオ経由でエージェントを作成するとこの新しいUIのビルダーが利用できるようになるようです。一部の用語も変わって、「トピック」は「サブエージェント」という表現になりました。


スクリプトベースでの設定も可能になったのでプログラミング的な設定作業も実施できます。AIエージェントにスクリプトを渡してどのように設定すればいいかというやりとりももしかしたらできるようになるのかと思います。


他には、SDRエージェント機能として、 「Qualfied」が登場しました。登場したというより、Salesforce製品の一つになったという形。さきほどの Piper もこの仕組みで構築されたものになるそうです。


Piperを動かす「Qualified」というプラットフォームって?


バックオフィス業務効率化のエージェントとして「Agentforce Operations」が発表されています。



最後にスペシャルゲストを迎えた事例紹介とエージェントアプリ開発のパートーナー企業の紹介がありました。


AIエージェントを使った業務効率化、これを実現するための仕組みがSalesforceに用意されていることがこの基調講演で紹介されていました。基調講演の内容についてはSalesforceブログにもまとめられています。



Salesforce+で動画も公開されています。

Salesforce+ 基調講演 Welcome to the Agentic Enterprise


基調講演以外の動作も公開されているようなのでSalesforce+のサイトで振り返りというのも楽しめそうです。

SFDC:Codex開発でHerokuアプリのGitHub Flow運用を試してみました

前回のGit Flowの記事の続きです。


GitHub Flow の開発手順についてまとめたものはこちら。

GitHub Flow 開発手法

ブランチの種類

・main → 常にデプロイ可能な状態を保つ長期ブランチ
・feature/* → 新機能追加用の作業ブランチ
・fix/* → 不具合修正用の作業ブランチ
・docs/* → ドキュメント更新用の作業ブランチ
・refactor/* → 振る舞いを変えない内部改善用の作業ブランチ
・test/* → テスト追加・修正用の作業ブランチ
・chore/* → 設定変更、依存関係更新、開発環境整備などの作業ブランチ

例)

feature/add-search-form
fix/login-error
docs/update-readme
refactor/split-auth-service
test/add-login-tests
chore/update-dependencies

※Pull Requestのタイトルでは feat:、fix:、docs: のようなprefixを使うことがあります。ブランチ名では feature/、fix/、docs/ のように付けることが多く、完全に同じ名前にする必要はありません。

GitHub Flowでは、長期的に運用するブランチは基本的に main だけです。新機能追加、不具合修正、ドキュメント更新などの作業は、main から一時的な作業ブランチを作成して進めます。作業ブランチ名は、作業内容が分かるように feature/add-search-form、fix/login-error、docs/update-readme のように付けます。


その他、codexで開発するときには codexプレフィックスを適用しています。(codexのデフォルト設定です。任意で変更可能)


GitHub Flow運用の開発の流れ

開発内容を決めてIssueの作成

最初に開発内容を決めます。今回は画面右上の新規取引先ボタンを、Salesforce標準と同じように「新規」ボタンへ変更し、色を白色にしてみるよう指示します。


Codexに開発指示を出します。ざっくりやりたいことを伝えればだいたい理解してくれます。Issueやブランチ作成などGitHub上の操作の自動実行は別途エージェント指示ファイルをつくったりしていますが、SalesforceやHerokuの機能のことはそのまま理解してくれます。


指示を出すと現在何をチェックして何をしているかが画面に表示されます。


まずはIssueが作成されて作業予定としての記録が残りました。

作業ブランチの作成と開発開始

開発開始時にmainブランチを元に作業ブランチを作成します。今回はprefixがcodexですが、実際はfeatureやdocsなど、役割に応じたprefixでブランチを作成します。


開発完了したらプルリクエストを作成

作業ブランチでの開発が完了しました。Codex側ではテストなども実行してくれています。作業ブランチの開発が終わったらプルリクエストを作成します。

プルリクエストのレビュー

レビューワーはプルリクエストで変更内容を確認して、レビュー結果を投稿します。GitHubにはレビュワーを設定したり、レビュー結果を登録したりする仕組みがあるので、そこで管理します。自分自身はレビューワーには設定できない仕組みです。GitHub Copilotの有料プランを契約していれば、ここでGitHub Copilotを指定することもできます。


HerokuアプリはデプロイされるまではHeroku側に反映されないので、まず動作確認はローカルでやります。開発者はCodexに指示すればdev serverの起動なども実施してくれます。


ブラウザはSafariやChromeなど任意のものを指定することもできますが、Codex内のブラウザも便利です。権限のある範囲でCodex側で操作して結果を確認してくれるのと、右クリックから注釈モードに切り替えることで、より細かな確認が可能になります。


内容に問題がなければ、レビューOKなどのやりとりをしてマージを許可します。

レビュー後のマージ

レビュー完了後にmainブランチにマージします。基本的にはデプロイを行うタイミングでのマージです。


Herokuの場合はHeroku Pipelineの仕組みを使って本番デプロイを管理できます。

(Review Appsは今回は使っていません)

mainブランチのマージが完了するとステージングアプリケーションに反映される

mainマージ直後に本番反映されるのではなく、一度ステージングアプリにのみ反映できます。ここでHeroku上での動作確認が可能です。即時適用ではなく、マージしてから少し経つとBuilding appの処理が動いて、完了後に反映されます。

ステージングアプリケーションで動作確認

Open AppのリンクをクリックするとHerokuアプリにアクセスできます。URLやブックマークは不要で便利です。

Promote to productionボタンで本番アプリにデプロイ

動作確認完了したら本番に反映するためのボタンをクリックします。


Promoteすると本番アプリに変更が適用されます。このときはほぼ即時反映の形で適用されました。(一からビルド処理は発生しませんでした。)

マージ後の後片付け

Codexにマージが完了したとコメントすると、Dev Serverが動いたままなら停止、ブランチをmainに戻す、不要なブランチの削除などを自動でやってくれます。このあたりは最初から良い感じに判断してくれるものもあります。判断してくれない場合も、AGENTS.mdに指示を書けば対応してくれる感じです。


GitHub Flow運用の開発の流れは、このような感じです。前回試したGit Flowでは、develop や release ブランチを使って、開発中の変更と本番反映する変更を分けて進めました。今回のGitHub Flowでは、長期的に運用するブランチを main に絞り、作業ごとのブランチとPull Requestで変更を進める流れになります。

Heroku Pipelineと組み合わせることで、main へのマージ後にStagingへ自動デプロイし、確認後にProductionへPromoteする流れも作れました。GitHub Flowは、ブランチ構成をシンプルに保ちながら、小さな変更を継続的に反映していく開発に向いています。

SFDC:レポートで必要となるステップアップ認証の適用スケジュール変更のメモ

6月に実施されるとアナウンスのあったSalesforceのセキュリティアップデートの一つでレポートで必要となるステップアップ認証が必須となる話があります。

https://help.salesforce.com/s/articleView?id=005321566&type=1


新しい要件が適用されたあとは大量レコードのレポートを参照したりエクスポートしたりする際にMFA認証が必須となる仕様に変わります。(クールダウン設定とか細かい制御はあり。)


事前の有効化の設定としてはID検証画面にあるセッションセキュリティレベルポリシーの設定のところ、ここのレポートおよびダッシュボードの選択肢にステップアップ認証関係の選択肢が追加されて事前の検証ではそれを設定すると有効化されます。ただ、添付画像のとおり選択肢に追加されるのは段階的にということでまだ選べない組織もありました。以下はDeveveloper Edtion組織なので他より更に後回しになっているのかも。


今回は任意で有効化できますではなく、必須要件となることで最初の予定では6月10日からの適用予定でした。

スケジュール変更の話

Trailhead Communityのやりとりで有効化実施にあたり解決すべき問題が見つかったということで、スケジュールの延期がきまったようです。


英語言語の方では新しいスケジュールに更新されていました。Chromeのブラウザ翻訳で確認できます。

ここの英語言語はヘルプページの一番下にある言語のところの話です。


日本語の方はまだ古い情報でした。まだ変更が決まった直後みたいです。

日本語言語に切り方時には日本向けの内容になります。たぶん翻訳などの関係で情報反映が少し遅れる形。


日本語版の公開ページはまだ古い日程ですが、英語版の方が正となるのでスケジュールは変更される形と考えて大丈夫かと思います。最終的に有効化が必要にはなるので準備は変わらず進める必要がある流れです。

関連記事

2026 年 6 月から開始されるセキュリティ強化に備える

https://successjp.salesforce.com/article/NAI-001221

SFDC:Codex開発でHerokuアプリのGit Flow運用を試してみました

CodexでHerokuのサンプルアプリ開発を試した際に、Git Flowの流れに沿って作業を進めてみました。ブランチ作成、PR作成、リリース用PRの作成までをやっています。Gitのブランチ運用には「Git Flow」と「GitHub Flow」の考え方があります。それぞれの進め方は以下のとおりです。

■Git Flow (今回やった方)
`develop` や `release` ブランチを使って、開発中の変更と本番反映する変更を分けて進める流れです。
 
■GitHub Flow (今の主流)
`main` ブランチを常にデプロイ可能な状態に保ち、作業ブランチとPull Requestで変更を進め、マージ後にデプロイするシンプルな流れです。Webアプリのように小さな変更を継続的にリリースする開発で使いやすい運用です。


Git Flowの開発についてまとめたものはこちら。

Git Flow 開発手順メモ

ブランチの種類

・main → 本番リリース済みの安定版を管理するブランチ
・release → developブランチからmainへ本番反映するときの一時的なブランチ
・develop → 開発統合ブランチ (長期的に運用)
・feature → 開発時の一時的なブランチ。終わったらdevelopへマージ。

※今回の開発はfeatureをcodexという名称にして作業しています。また、Git Flowでは本番リリース後の緊急修正用に `hotfix/*` ブランチを使うこともあります。今回は通常開発からリリースまでの流れを試したため、hotfix は扱っていません。

開発指示とIssueの作成指示

Codexを使って次のような画面のHerokuアプリを作成しました。Salesforce APIを使って取引先と取引先責任者のデータを取得して画面に表示しているアプリです。


今回は不要なテキスト文言の除外に関する作業指示を出します。取引先ページにある「- ビュー: 自分の取引先」と取引先責任者ページに「 - ビュー: 自分の取引先責任者」の文言を削除します。


Codexに開発指示をします。そのときにIssueの作成も依頼できます。指示はざっくりした内容でもCodex側が良い感じに整理してくれます。


プロジェクトと関連付けているGitリポジトリの情報をチェックして何が必要か判断してくれます。


Issueもこのように作成してくれます。開発開始時にはdevelopブランチを基準として、feature (codex) ブランチを作成し、作業を行っています。

featureブランチでの開発

Issue作成後にそのままの流れで開発対応を開始してくれます。作業中は細かく今何をチェックして何をしているかという情報が表示されます。


作業結果です。最終的に要約された作業結果の情報が表示されます。事前の設定でプルリクエストの作成やGit Flow運用での開発を指示している状態です。


今回の構成では、プルリクエストをマージするまではHeroku上のステージング環境に反映されないため、まずローカル環境で開発結果を確認します。


指示どおりに不要なテキスト文言が修正されていることを確認できました。

featureブランチからdevelopブランチへのマージ

ローカル環境での動作チェックができたら、featureブランチからdevelopブランチへのマージを行います。


developブランチへのマージがされるとHerokuのステージング用アプリの方に自動反映される設定を別途しています。これでHeroku上で動作確認できるので今回の修正が行われているかをチェックできます。今回は想定どおりに変更できていることを確認できたので次に進めます。

developブランチ→releaseブランチ→mainへのマージ

Codexにdevelopブランチへのマージが完了したことを伝えると後処理をしてくれるようにしています。


developブランチへのマージが完了したら、次の工程は本番へのリリース (mainへのマージ)です。


リリースのため、developブランチからreleaseブランチを作成します。


環境設定しておくとCIのチェック等必要な対応を行ったうえでプルリクエストを作成してくれます。不要な変更などが出た場合も判断して修正しつつ作業が進みます。


これで本番リリース用のプルリクエストが用意されました。

本番リリース (mainのマージ)

プルリクエストが用意されたら、内容を確認します。


内容に問題がなければマージします。別途設定でmainにマージしたタイミングでHerokuの本番アプリにデプロイされるように設定しています。デプロイ処理に少し時間がかかりますが、少し待てばHeroku側に反映されます。

mainマージ後の工程

Herokuアプリへのリリースが完了したらCodexにマージ完了の連絡を行います。マージ後の後片付けとして、release/* から develop への戻し PRのチェックと不要ブランチの削除などが実施されて開発対応完了です。


気になる場合は必要な対応が全部完了したかも相談できます。


Git Flowの運用の流れのまとめです。

develop から feature/... 作業ブランチを作成

feature/... で開発

develop 向け通常開発 PR

develop にマージ

develop から release/... ブランチ作成

main 向け release PR

main にマージして本番反映

必要なら release/... から develop へ戻し

release branch 削除


開発を進めていくと、プルリクエストは次のように並んでいきます。

featureブランチからdevelopブランチへのプルリクエストは、作業内容に応じて `fix:` や `refactor:` などのプレフィックスを付けています。一方で、developブランチから作成したreleaseブランチをmainへマージするプルリクエストには、`release:` プレフィックスを付けています。

※今回は1機能ごとにreleaseブランチを作成していますが、Git Flowでは複数の変更をまとめてリリースすることが多いため、実際の運用ではreleaseのプルリクエストはここまで頻繁には作成しない想定です。


Git Flowは、作業ブランチの変更をいったんdevelopブランチに集約し、リリース対象がまとまったタイミングでreleaseブランチを作成して本番反映する運用です。そのため、GitHub Flowのように小さな変更をmainへマージしてすぐデプロイする流れよりも、複数の変更をまとめてリリースする運用に向いています。


Codexを使ったHerokuアプリ開発でも、Git Flowの流れに沿ってこのように進めることができました。一方で、今回のようなWebアプリを小さく継続的に改善していく場合は、Git FlowよりもGitHub Flowの方が運用を軽くできる場面もあります。

関連記事


続き : GitHub Flowの話

tyoshikawa1106.hatenablog.com