プロンプトからワークフローへ：AIでフロントエンド開発の生産性を向上させる

もはや最大のボトルネックはコーディング速度ではありません。問題は入力の断片化と、それらをつなぎ合わせるコストです。

あらゆる機能で私たちは複数のシステムを横断する必要があります。要件はJira、デザインはFigma、ドキュメントはConfluence、確認はSlack、実装はGit。フロントエンド開発者は、仕様・デザイン・要件・計画などの入力が収束する地点に位置し、それらをユーザーが実際に使える形に組み立てる役割を担っています。

長年にわたり、フロントエンドの負担は、チケットを読み、デザインファイルを確認し、エッジケースを明確にし、プロダクトやバックエンドチームと絶えず同期することで情報を吸収・統合する我々の能力に大きく依存してきました。

このようなコンテキストの切り替えや多くの手作業は、大規模言語モデル（LLM）の助けで自動化できるようになってきています。LLMがより多くのコーディングを担うにつれ、フロントエンド開発はコーディングの問題というよりもオーケストレーションの問題へと変わってきています。

変化：プロンプトからワークフローへ

AIに対する本能的な反応は、巧妙なプロンプトを書いてそれに期待することです。それは一度はうまくいきますが、累積的に機能しません。

ワークフローは異なります。ワークフローは入力から出力への再現可能な経路です。作業が既に存在するシステム（Jira、Confluence、Slack、コード）全体からコンテキストを収集し、実際に求められていることを要約し、不明点を明らかにし、その後実装計画を提案します。そしてコードに触る前に人間のレビューを待ちます。

AIはワークフローを実行する実行エンジンです。

LINEヤフー株式会社では、すでに社内の多くの素晴らしいチームによって強力なエコシステムが構築されています。例としてNoah MCPがあります。Jira、Confluence、Slack、GitHubなどのツールを接続することで、私たちが日々個別に参照しているデータをAIエージェントが読み取り、推論し、行動できる連結された入力に変換します。これにより、AIは手動でプロンプトに貼り付けたコンテキストに限定されず、日常のワークフローに既に存在する実際のコンテキストで動作できます。

同じワークフローはすべてのチケットで動きます。入力は変わっても、パターンは変わりません。それがスケールする理由です。

ワークフローのエンドツーエンドの姿

具体例として、通常どのように進行するかを示します。

チケット：Jiraのチケットが、検索、フィルタ、ソート、役割に応じたフィルタ表示を備えたリストページの作成を要求します。

以前のやり方：

1. チケットを開いて二度読みします：ソート／フィルタ／検索は記載されていますが、フィルタ状態をリフレッシュ後に保持するか、共有可能にするかについては何も書かれていません。
2. Figmaを開きます：リストの空状態、ローディング、結果なしの状態、およびフィルタパネルを確認します。
3. Confluenceで機能を検索：フィルタルールに関するページを見つけ、どのロールにどのフィルタが表示されるかを確認します。
4. Slackを検索（数百件のメッセージが含まれることがあります）：先月のスレッドで別チームが合意しているか、企画者によって未確定だったかを発見することがあります。
5. コードベースを開く：既に別の機能でuseTableFiltersとuseUrlStateフックが存在することに気づきます。再発明せず再利用すべきです。
6. メモファイルを開き、各ソースからの断片を貼り付けて、まとまった計画を組み立てようとします。
7. 開発中：コードを実行してあらゆるバグやエッジケースと闘い、型やリンティング規約の問題などを解決します。
8. サイクルの終了：リポジトリへプルリクエスト（PR）を提出します。

新しいやり方：
ワークフローを起動します。

- Read Jira ticket FE-1234.
- Find related Confluence docs on filter rules and role-based visibility.
- Search Slack for recent decisions on this list page or filter behavior.
- Look for similar list/filter implementations in the codebase.

Do not modify code yet.
Return: requirement summary, frontend impact, files involved,
implementation checklist, test checklist, open questions.

数分後、エージェントは次のような結果を返します。

## Requirement summary

Build a list page for the <Feature> module with search, filter, and sort.

Integrates with the existing GET /api/<feature> endpoint (already paginated).

Filter set depends on the current user's role.

## Frontend impact

- New `<FeatureListPage />` route + container
- New `<FeatureList />` component reusing existing table primitives
- Search / filter / sort UI wired to the shared filter hook
- State sync: filter + sort + page must round-trip through the URL

## Files likely involved

- src/features/<feature>/FeatureListPage.tsx        ← new route
- src/features/<feature>/FeatureList.tsx            ← new
- src/hooks/useTableFilters.ts                      ← reuse
- src/hooks/useUrlState.ts                          ← reuse
- src/components/ui/SearchInput.tsx                 ← reuse
- src/components/ui/FilterPanel.tsx                 ← reuse
- src/api/<feature>.ts                              ← already exists

## Role-based filter visibility (from Confluence: "<Feature> Access Matrix", updated 2026-04)

- viewer  → search, status filter, date range
- editor  → + owner filter
- admin   → + internal-only flags

## Implementation checklist

- [ ] Add route and page container
- [ ] Wire search / filter / sort to useTableFilters + useUrlState
- [ ] Gate admin-only filters behind useCurrentUserRole()
- [ ] Empty / loading / no-results states per Figma

## Test checklist

- [ ] Filters round-trip through URL params (reload preserves state)
- [ ] Shareable URL renders the same filtered view for another user
- [ ] Role-based filters are hidden for lower-privilege users
- [ ] No-results state renders correctly

## Open questions

1. Filter and sort state: store in URL params or localStorage? (Slack thread 2026-04-12 in #frontend-platform suggests URL params for shareability)
2. Should the empty state offer a "clear filters" CTA, or just "no results"? (Figma shows both variants without indicating which is final.)

上記がプランの例です。すぐに目立つ点が三つあります。

1. Slackスレッドで隠れた要件が明らかになった：フィルタの状態はlocalStorageではなくURLに保持されるべきです。これがPRレビューでしか表面化していなければ、実装途中で作り直しが必要になっていた唯一の問題でした。
2. 再利用できる既存フックが二つある：(useTableFilters, useUrlState)、新しいものを考案する必要はありません。
3. 解決すべき未解決の質問が二つある：コードを書き始める前に解決するべきです。

次に、プランを確認し未解決の質問を確定した後、Code Agentは高い確信を持って実装を開始できます。その結果、非常に高品質な成果が得られます。

しかし、機能を実装するだけで終わらせてはいけません。完全なワークフローはコーディング後のフォローアップも必要です。強力なワークフローはクローズドループの開発サイクルを持ちます。

Code Agentが最初の実装を終えたら、次のステップはエージェント自身にプランに対して作業を検証させることです。

同じワークフローが続きます。エージェントは元のプランを取り、それを検証ループに変換できます。

Implementation is done.

Now verify the work against the original plan.

Run:
- typecheck
- lint
- related unit tests
- relevant smoke test or local verification flow

Then return:
- what passed
- what failed and was fixed
- what could not be verified automatically
- screenshots or notes for UI states
- remaining risks before PR

ここがLLMが特に有用な場面です。多くのフロントエンド保守作業は概念的に難しくはありませんが、時間がかかり、急いでいると見落としがちです。TypeScriptエラーの修正、テストモックの調整、リンティングルールの順守、エッジケースの確認、スナップショットの更新、あるいは実装がコードベースの他の部分と同じ慣習に従っていることの確認などが該当します。

出力は次のようになります。

## Verification summary

Typecheck: passed
Lint: passed
Unit tests: passed
Smoke test: partially verified locally

## Tests added / updated

- Added tests for URL state persistence when filters change
- Added tests for role-based filter visibility
- Updated no-results state test to match the Figma copy

## Smoke test result

Verified manually in local environment:

- Search updates the URL query params
- Refresh preserves search / filter / sort state
- Viewer role cannot see owner or internal-only filters
- Admin role can see all filters
- Empty state renders correctly when the API returns no rows

## Issues found and fixed

1. Filter state was reset when changing page number
   Fixed by preserving existing URL params inside `useTableFilters`.

2. Admin-only filter was hidden on first render because user role loaded async
   Fixed by rendering the filter panel only after role resolution.

3. No-results state used the generic empty text instead of the Figma-specific copy
   Fixed by reusing the correct translation key.

## Could not verify automatically

- Shareable URL behavior for another user role requires a real account with different permissions.
- Final empty-state CTA decision still depends on PM / Design confirmation.

## Remaining risk before PR

The implementation follows the current Confluence access matrix, but if the role rules change before release, the filter visibility logic needs to be updated.

これにより、エージェントは単なるコード生成器から、実装・実行・失敗・修正・検証・報告という退屈だが重要なループを完遂できる開発パートナーへと変わります。

さらに、Code Agentにアプリの実行権限を与え、安全な環境で実際のAPIを呼び出したり、Playwrightでスモークテストを実行できるようにすれば、成果はさらに安定します。エージェントはコードを書くことだけでなく、自ら結果を検証できるべきです。

例：

Run the local app and smoke test the feature.

Check:
- loading state
- empty state
- search
- filter
- sort
- pagination
- URL refresh behavior
- role-based visibility

Do not create a PR yet.
Return screenshots, failed cases, and suggested fixes.

これがワークフローの真の価値です。計画段階で集めた同じコンテキストが、実装・テスト・デバッグ・引き渡しの各段階で再利用されます。エージェントは各ステップで要件を再発見する必要がなく、常に作業を元の計画と比較し続けることができます。

検証ループが十分に整ったら、最後のステップは引き渡しです。

エージェントはすでに必要なコンテキストを持っています。

• チケットが要求している内容
• どのファイルが変更されたか
• どの決定がJira、Confluence、Slack、またはFigmaに由来するか
• どのテストが追加されたか
• どのチェックが通過したか
• どのリスクがまだレビュワーの注意を必要としているか

これにより、同じチームの規約に沿ってPRを準備できます。

Prepare the PR.

Read the project PR template and recent merged PRs in this area.
Summarize the change using the team convention.
Link the Jira ticket.
Include test evidence.
Call out remaining risks or manual verification notes.
Do not hide unresolved questions.

PRの説明は一般的なものにしてはいけません。ワークフロー全体の最終的な要約であるべきです。

## Summary

Implemented `<Feature>` list page with search, filters, sorting, pagination, and role-based filter visibility.

## Key behavior

- Search / filter / sort state is synced to URL params
- Viewer, editor, and admin roles see different filter sets based on the access matrix
- Empty, loading, and no-results states follow Figma
- Existing `useTableFilters` and `useUrlState` hooks are reused

## Verification

- Typecheck: passed
- Lint: passed
- Unit tests: passed
- Local smoke test: completed

## Notes for reviewers

- URL state behavior follows the Slack decision from 2026-04-12
- Empty-state CTA still needs final Design confirmation
- Shareable URL behavior across different user roles requires staging verification

これがクローズドループのワークフローです。

Gather context
→ Return plan
→ Resolve open questions
→ Implement
→ Run checks
→ Fix failures
→ Smoke test
→ Summarize verification
→ Prepare PR

コンテキストは開発サイクル全体を通じて保持されます。

計画は間違った実装を防ぎ、テストは脆弱な実装を防ぎ、スモークテストは理論上だけで機能する実装を防ぎます。PRの引き渡しは、レビュワーが散在するコミットから全体像を再構築する手間を省きます。これがワークフローを完全にする理由です。

この魔法を実現するには？

ワークフローライブラリを用意する必要はありません。必要なのは、良いプロンプト運用の規律と検証済みのMCP設定です。

1. エージェントがツールにアクセスできることを確認する（初回のみ）

claude mcp list
# or
codex mcp list

想定されるサービス：

jira
confluence
slack
github
figma

任意で探索を推奨：

design.md
playwright

何か不足がある場合は、セットアップガイドがWikiやドキュメントにリンクされています。

• Claude Code MCP のセットアップ
• Codex CLI MCP のセットアップ
• Design.md（コーディングエージェント向けにビジュアルアイデンティティを記述するため）

2. 各ツールが提供するもの

3. 「プランモード」を使って実チケットでワークフローを実行する

Claude Code を使用している場合：実行前にプランモード（/plan）をオンにしてください。プランモードはまだコードを変更しないことを構造的に強制する仕組みです。エージェントは検索、読み取り、計画を行えますが、明示的に承認するまではファイルに書き込めません。これにより、境界が単なる文章での指示から保証へと変わります。他のコーディングエージェントツールのプランモードと同じであるべきです。

4. コードに手を加える前に出力を確認する

特に未解決の質問のセクションを確認してください。エージェントがあなたが見落としていた良い質問を一つでも提示したなら、そのワークフローは既に投資に見合う価値があります。

5. クローズドループな開発を準備する

コードベース内で、LLMが読み取り従えるコード規約を整備してください。管理する最適な場所はSKILL.md または Custom Slash Commands です。常にテストスイートと組み合わせて作業してください。

6. 最終レビューと引き渡しの準備

引き渡し条件はプラン内で満たされ、PRやGit運用のチーム規約と組み合わされているべきです。ここで重要なのは明確に定義された規約とテンプレートです。

なぜこれが有効か：実行する前に理解する

上記のワークフローが有用な出力を生む理由は、プロンプト自体ではなく順序にあります。エージェントはコードを変更してよいと許される前に、コンテキストを収集し、要約し、質問を行います。その順序こそが、ワークフローを初心者的なプロンプト操作と区別するものです。

これが成立する要素は主に三つです。

• 明確なコンテキスト。 エージェントはどこを参照すべきか（Jira、Confluence、Slack、コード）と何を返すべきか（上のプロンプトでの6つの見出し）を知っています。曖昧な指示は曖昧な結果を生みます。
• 境界の設定。 コードをまだ変更しないという一行がほとんどの「AIがやりすぎた」失敗を防ぎます。Claude Codeではプランモードがこれを構造的に強制し、承認されるまでエージェントはファイルを書き込めません。エージェントは変更して良いものと参照すべきものを明確に知るべきです。
• 構造化された出力。 固定されたパターンにより出力を簡単にレビューできます。要約、ファイル、チェックリスト、テスト、未解決の質問が常に同じ順序で現れることで、迅速にスキャンして不足を見つけ、次のステップを承認する前に計画と実際の要件を比較できます。

フロントエンド開発では、多くのミスは構文の誤りではなくコンテキストの誤りです。コンポーネントはコンパイルし、UIはレンダリングされ、テストは通る。しかし挙動が間違っているのは、エージェントが業務ルールを見落としたり、デザイン制約を無視したり、ユーザーフローを誤解したりしたためです。実行前に理解を強制することが、最も効果的なタイミングでそれらを検出する方法です。

だからこそ、プロンプトの構築方法を深く理解することが、フロントエンド開発における次の重要なスキルなのです。単一のプロンプトは単一のタスクを助けますが、ワークフローはやるべきことの全体コンテキストを把握するのに役立ちます。

---

何が問題になり得るか？

AIワークフローは大きな利点をもたらしますが、注意しないと混乱を招くこともあります。適用方法を十分に理解していない場合の一般的な誤りは次のとおりです。

出力をあまりに信用しすぎること。 エージェントが適切なツールへアクセスできても、要件を誤解したり、エッジケースを見落としたり、間違った仮定をすることがあります。出力が自信満々に見える場合は特に危険です。きれいに動いている実装が必ずしも正しい実装であるとは限りません。開発者は常に主導権を握り、理解負債（comprehension debt）を大きくしすぎないよう注意する必要があります。

一度にすべてを自動化しようとすること。 チケットを読み、すべてのシステムを検索し、コードを変更し、テストを書き、PRを作成し、Slackに更新を投稿するという大きなワークフローを作るのは魅力的ですが、制御が難しくなります。問題が起きたときにどのステップが失敗したか理解するのが難しくなります。経験則として、READ（読み取り）とWRITE（書き込み）を分離してください。まずPLANNINGを行い、その後EXECUTEするべきです。

AIは制約の下で最もよく機能することを忘れること。 制約がないと、エージェントは過剰に変更したり、誤ったパターンを使ったり、既存アーキテクチャに合わないコードを生成する可能性があります。境界が具体的であるほど実行は安全になります。最も効果的なワークフローは最も自動化されたものではなく、再現可能でレビュー可能でチームの働き方に合致したものです。

---

ワークフローの適用と拡張事例の紹介

計画からPRへ

それでは、ワークフローを使ってJiraチケットからPRまで全てを生成してみましょう。以下は、ワークフローを実行するためのプロンプトの例です。

- Read Jira ticket EXP-4513.
- Find related Confluence docs on filter rules and role-based visibility.
- Search Slack for recent decisions on this list page or filter behavior.
- Look for similar list/filter implementations in the codebase.

Do not modify code yet.
Return: requirement summary, frontend impact, files involved,
implementation checklist, test checklist, open questions.

出力：

EXP-4513: Improve 'Live schedule' item - Requirements Analysis (Final)

1. Requirement Summary

Goal: Clarify the "Live schedule" field purpose based on live type to reduce user confusion.

Key Changes:

1. Create/Edit Live Video Form:
  - Live stream: Hide the "Live schedule" field entirely
  - Pre-recorded video: Show "Live schedule" with updated description text
  - Update description: "Schedule a time for your pre-recorded video. It will start automatically at the scheduled time and can also be started manually".

2. Live Board Page:
  - Live stream: Hide "Scheduled date" label and date in "Release" section for scheduled status
  - Pre-recorded video: Show "Release" tab with scheduled date
  - Only display scheduled date for pre-recorded videos; live stream shows live date only after going on-air

3. Live Videos List Page:
  - Rename column from "Live date" to "Live status & Live date"
  - Add info icon tooltip with explanations:
    - Title: "Live date"
    - Scheduled: "Scheduled time (Pre-recorded only)"
    - On-air: "Actual live start time ~"
    - Finished: "Actual live start time ~ end time"
  - Hide scheduled dates for live stream broadcasts in Scheduled status

Frontend Impact

	Behavior Changes:
	- Conditional rendering based on broadcastType
	- Scheduled date visibility rules differ by broadcast type and status
	- UI text updates across 3 main areas

	Data Requirements:
	- broadcastType field must be available in all contexts
	- scheduledLiveStartTime field
	- broadcastStatus field
	- No new backend fields required

	UX Improvements:
	- Clearer distinction between live stream and pre-recorded behavior
	- Reduced confusion about when scheduled dates apply
	- Better information architecture with tooltip guidance

Files Involved

	Components to Modify:

	1. Create/Edit Live Video Form:
  	- <project-root>/src/components/createEditLiveVideo/form/basicInformation/BasicInformationForm.tsx
    	- Conditional rendering of Live schedule field

	2. Live Board Page:
  	- <project-root>/src/components/liveBoard/LiveBoardInformation/LiveBoardInformation.tsx
    	- Release section rendering logic
    	- Schedule date rendering function
	...
	...
	...

Implementation Checklist

	Phase 1: Pull Latest Translations

	- Run the project translation sync command
	- Verify required translation keys are available in message files
	- If keys are missing, coordinate with design/PM team

	Phase 2: Basic Information Form

	- Add conditional rendering for Live schedule field based on broadcastType
	- Show Live schedule only for pre-recorded videos
	...
	...
	...

	Unit Tests
		Create/Edit form shows or hides schedule field based on broadcastType
		Date display logic returns empty string for Live stream + Scheduled
		Date display logic returns scheduledLiveStartTime for Pre-recorded + Scheduled
		Tooltip content renders with correct translation keys

	Integration Tests
		Scenario 1: Create Live Stream
			Live schedule field is not visible
			Can create without setting schedule
			Validation for schedule is skipped
			Live Board Release section shows no scheduled date when status is Scheduled
			List view shows blank date cell when status is Scheduled
			After going On-air, date appears as actual live start time
		Scenario 2: Create Pre-recorded Video
			...
			...
			...
	Browser/Device Tests
		Chrome desktop
		Firefox desktop
		Safari desktop
		Mobile responsive layout
		Tooltip positioning correct on all screen sizes
		Table column width adjusts properly with new header

	Accessibility Tests
		Tooltip accessible via keyboard
		Screen reader announces column header text
		Info icon has proper aria-label
		Blank date cells do not cause screen reader issues

	Open Questions
		Existing Scheduled Live Streams:What happens to live stream broadcasts that already have scheduledLiveStartTime in the database?
		Recommended approach: hide the date per new spec
		Alternative: show with a deprecation notice
		API Validation:Does the backend still accept scheduledLiveStartTime for live stream broadcasts?
			If yes: add frontend validation to prevent it
			If no: rely on backend validation
		...
		...
		...

実装が完了したら、同じワークフローを使用してPRを作成できます。

From the code changes,
- reads the project's commit convention and PR template
- groups them into commits
- opens a draft PR linked back to the ticket

出力例：

⏺ Bash(git add . && git commit -m "EXP-4513: Improve 'Live schedule' item ")
  ⎿  > example @1.2.0 pre-commit
  Searched for 1 pattern, called github (ctrl+o to expand)
...
⏺ PR created: https://githum.com/org-example/example-project/pull/900

  - Committed as EXP-4513: Improve 'Live schedule' item .
  - Opened PR #900 against release/v1.2.0.

Slackスレッドから計画へ

機能の真の情報源がJiraチケットやConfluenceページではなく、2週間にわたって続いた150件以上のメッセージを含むSlackスレッドであることがあります。PM、デザイナー、バックエンド、QA、ステークホルダーが関わると、チケットが回ってくる頃にはどの決定が最終か、どの提案が却下されたか、どの質問が未回答かを誰も覚えていないことがよくあります。

同じワークフローパターンでこれに対処できます。エージェントにスレッドを提示し、同じ境界（コードはまだ変更しない）を設定して、30分かけてスクロールして読み返す代わりに構造化された計画を返すように依頼します。

<!-- this is just simple example, you should create commands or skill for those task also as a workflow -->
- Read Slack thread <link> in #live-platform from 2026-05-01 onwards (~180 messages, 9 participants).
- Cross-reference with Jira ticket GLPEX-4720 and any Figma frames linked in the thread.
- Look for similar implementations in the codebase.

Do not modify code yet.
Return: thread summary, confirmed decisions (with message timestamps),

rejected proposals, open questions, files likely involved, suggested implementation plan.

出力例：

## Thread summary
Slack #example-project, 2026-05-01 → 2026-05-14, 184 messages, 9 participants.
Topic: rollout of "scheduled go-live reminders" for the Live module.
Started as a PM proposal, expanded into design / backend / frontend negotiation.

## Confirmed decisions (with message timestamps so you can verify)

- 2026-05-03 @taro.pm     Reminders fire at 10 / 5 / 1 min before scheduled start.
                          Reconfirmed 2026-05-09.
- 2026-05-06 @yuki.design Use the existing toast component, not a modal. Figma frame linked.
- 2026-05-08 @minho.be    Backend exposes `scheduledLiveStartTime` on /live/upcoming.
                          No new endpoint.
- 2026-05-12 @taro.pm     Pre-recorded videos only. Live streams excluded from v1.

## Rejected proposals (kept here so they don't resurface in review)

- Push notifications via APNs           rejected 2026-05-04 - out of scope for v1
- Separate "Reminders" tab in nav       rejected 2026-05-07 - duplicates schedule view

## Open questions still unresolved in the thread

1. Timezone: viewer's local tz vs broadcaster's tz?
   Last touched 2026-05-10 by @yuki.design as a question, never answered.
2. Dismiss behavior: does dismissing the 10-min reminder also suppress the 5-min and 1-min?
   Mentioned twice, no decision recorded.
3. Reload behavior: should a dismissed reminder come back after page refresh?

## Files likely involved

- src/features/live/hooks/useUpcomingLiveReminders.ts   ← new
- src/features/live/components/LiveReminderToast.tsx    ← new
- src/components/ui/ToastStack.tsx                      ← reuse
- src/api/live.ts                                       ← extend with /live/upcoming

## Suggested implementation plan (gated on the 3 open questions above)

- [ ] `useUpcomingLiveReminders(broadcastId)` hook subscribes to /live/upcoming on mount
- [ ] Schedule the 10 / 5 / 1 min reminders client-side, reuse <ToastStack />
- [ ] Dismiss state in sessionStorage (until Q3 is resolved)
- [ ] Gate the feature behind `broadcastType === 'pre-recorded'`

## Recommended next action

Don't start coding yet. Post the 3 open questions back into the thread, tag @taro.pm and
@yuki.design, and wait for explicit answers. The thread does not contain them - re-reading
won't help.

入力が184件ものノイズを含むスレッドであっても、これが有用である理由は二つあります。

• 何が決定されたかと何がまだ議論中かを分離して示します。スレッドは長すぎて新しく参加する人が毎回読み直すのは困難です。エージェントは一度その作業を行い、検証できるようにタイムスタンプを添えて示します。
• 答えを創作しません。スレッドで結論に至っていない場合、エージェントはその旨を示して人間へ返します。3週間後にバグになるようなもっともらしい推測を生成することはありません。

このパターンはプランからPRへの流れと同じです。先に読む、次に構造化する、欠けている点を表面化する、コードはまだ変更しない。入力ソースが単一のチケットから長期の多ステークホルダースレッドへ変わっただけで、パターンは変わりません。これがワークフローの本質です。

おわりに

フロントエンド開発は、プロダクトの意図、デザインの判断、業務ルール、バックエンド契約、ユーザーからのフィードバック、そしてコードといったすべてが集まる地点に位置します。私たちの立場では、AIがここで私たちの役割を新たなレベルへ引き上げるでしょう。

フロントエンドエンジニアにとって次に重要なスキルは、単なるプロンプト作成だけではないかもしれません。それはコンテキストエンジニアリングです。どの情報が重要か、どこで見つけるか、どのように構造化するか、そしてAIを安全に導く方法を知ることです。

したがって目的は判断を自動化してなくすことではありません。目的は、判断を理解し適用しやすくするワークフローを構築することです。

コンテキストをうまく管理できるフロントエンドエンジニアは、AIを単に速度向上に使うだけでなく、システム全体をより良く動かすために使えるようになるでしょう。

Tech-Verse 2026 を開催します（6月29日）

この記事は、イベントの公式記事として公開されました。
Tech-Verse 2026は、LINEヤフーが開催する技術カンファレンスです。
最先端の挑戦や積み重ねてきた知識を共有します。

YouTube LIVEでの配信をぜひご覧ください。
https://tech-verse.lycorp.co.jp/2026/ja/