フロントエンドのポジションに応募しようとすると、何から見ればいいのか分からなくなることがありますよね。ブラウザからJavaScript、React、CSSまで範囲が広くて、どこから手をつければいいのか見当がつかないんです。 そこで、以前応募の準備をしながら集めていたメモを、概念単位で整理し直してみました。説明が書いてあった概念は文章にして、キーワードだけ書いてあったテーマは自分で答えてみるためのチェックリストとして残しています。 ブラウザ ブラウザのレンダリングの仕組み ブラウザのレンダリングとは、HTML、CSS、JavaScriptといったリソースをブラウザが画面に描画する過程のことです。順序は大きく5つの段階に分けられます。 DOMの生成 — HTML文書をパースしてタグをノードに変換し、ノード同士の階層関係を作ってDOMツリーを構築します。 CSSOMの生成 — CSSをパースしてプロパティをノードに変換し、同じように階層関係を持つCSSOMツリーを構築します。 レンダーツリーの生成 — DOMツリーとCSSOMを結合しますが、このとき実際に画面に表示される要素だけを選んでレンダーツリーを作ります。 レイアウト — レンダーツリーをもとに、各要素のサイズと位置を計算します。 ペインティング — 計算された位置に、要素の背景、枠線、文字などを実際に描画します。 ブラウザでさらに見ておきたいテーマ 以下はメモにキーワードだけ残っていたテーマです。一文で説明できるかどうか、自分で確かめてみてください。 ブラウザの動作の仕組み URLを入力したときに起こること データの暗号化通信 XSSの防止 フロントエンドにおけるブラウザ性能の測定方法と、改善点を見つけるために見るべきもの JavaScript ホイスティング ホイスティングとは、変数や関数の宣言がスコープの先頭に引き上げられたかのように実行される現象です。そのため、宣言前に使うと意図しないエラーが起きることがあります。 ==と===の違い ==は等価演算子で、2つの値を比較するときに先に型変換(type coercion)を行います。データ型が違っても自動的に型を揃えてから比較するため、予想外の結果になることがあるんです。 ===は厳密等価演算子で、データ型と値の両方が同じかどうかを比較します。型変換なしで正確に値を比較するので、より安全で結果を予測しやすいです。 クロージャ クロージャは、関数が宣言されるときに自動的に作られるレキシカル環境と関係しています。このレキシカル環境は、関数が宣言された時点のすべての変数と関数を含むレキシカルスコープを形成し、それがスコープチェーンへとつながります。 おかげで、外側の関数が実行を終えて戻った後も、内側の関数は外側の関数のスコープにある変数にアクセスし続けられます。主に情報の隠蔽のために使われます。 非同期関数とイベントループ 非同期関数とは、実行結果がすぐには返らず、特定の条件が満たされるまで待つ関数です。通常はコールバック関数かPromiseオブジェクトを返します。 コールバック関数 — 非同期処理が完了したときに呼び出される関数です。 Promise — 非同期処理が成功したか失敗したかを表すオブジェクトです。 非同期関数はアプリケーションの性能を高め、ユーザーインターフェースの応答性を保つのに役立ちます。ただし、コールバック地獄のような問題を避けるには、適切なエラー処理とコード構成が必要です。 複数の非同期関数が実行されると、イベントループが呼び出しを処理し、各処理が完了したときにコールバックを呼び出します。つまり、非同期関数の実行順序はイベントループが制御しているわけです。 JavaScriptでさらに見ておきたいテーマ var、let、constの違い イベントループの動作原理 JavaScriptで最もよく使うデータ構造とアルゴリズム、それぞれの用途 イベント イベントバブリング イベントバブリングとは、HTMLでイベントが発生したとき、その要素で処理された後に上位の要素へイベントが伝播していく現象です。伝播している間、親要素でもイベントを検知できるのが利点です。 イベントデリゲーション バブリングを活用すると、親要素にハンドラを1つ登録するだけで、子要素で発生したイベントをすべて処理できます。複数の下位要素のイベントを1つのハンドラにまとめるこの手法をイベントデリゲーションと呼びます。 バブリングやキャプチャリングを止めたい場合は、イベントオブジェクトのstopPropagation()メソッドで伝播を止めるか、ハンドラの中でイベントが発生した要素を確認して処理すればいいです。 イベントでさらに見ておきたいテーマ ユーザーとのインタラクション CSS FlexとGridの違い Flexは主に1つの軸方向のレイアウトを組むときに使います。アイテムのサイズが自由で柔軟に変化できるので、レイアウトが流動的に変わる状況に向いています。 Gridは2次元のグリッドシステムを組むときに使います。水平方向と垂直方向の両方を整列でき、アイテムのサイズをあらかじめ定義して各セルのサイズを一定に保つので、レイアウトの変化が少ない場合に適しています。 CSSでさらに見ておきたいテーマ Webページの構成方法 CSSのスタイリング方法と、CSS宣言の構文・文法・各部分の呼び方 HTML5とCSS3の主な機能と最新トレンド Reactとアーキテクチャ クラスコンポーネントと関数コンポーネントの違い Reactでコンポーネントを作る方法には、クラスコンポーネントと関数コンポーネントがあります。クラスコンポーネントはES6のクラスで定義し、関数コンポーネントは関数で定義してフック(hook)APIと一緒に使うことが多いです。 最大の違いは、状態とライフサイクルの扱い方です。 クラスコンポーネント — 状態をthis.stateで定義し、ライフサイクルメソッドをオーバーライドして処理を行います。状態やメソッドを参照するときはthisキーワードを使います。 関数コンポーネント — 状態はuseStateフックで定義し、ライフサイクルはuseEffectフックで扱います。thisキーワードは使いません。 この違いのおかげで、関数コンポーネントのほうが簡潔で読みやすくなります。テストやリファクタリングもしやすいです。 MVVMパターンとFluxパターンの違い MVVMは、データバインディングでViewとViewModelの間に双方向のデータフローを保ちます。ViewModelがViewとModelの間でデータを仲介する構造です。AngularやVue.jsなどのフレームワークで使われています。 Fluxは、Action → Dispatcher → Store → Viewという単方向のデータフローを使います。Storeがアプリケーションのデータとビジネスロジックを担当し、Dispatcherを通じてActionを処理します。主にReactで使われています。 テストの観点でも違いがあります。Fluxは単方向フローと単一責任の原則に従うのでテストしやすいコードを書きやすい一方、MVVMは双方向バインディングのためにテストが難しくなることがあります。 Reactでさらに見ておきたいテーマ Reactの動作原理 Reactのライフサイクル 状態管理の方法 Reactのuseで始まる関数たち マイクロフロントエンド React、Vue、Angularなど主要フレームワークの長所・短所と選び方 プロジェクト経験の伝え方 概念と同じくらい大事なのが、プロジェクト経験を具体的に伝えることです。実際にどんな問題をどう解決したのか、どんな技術的な決定をなぜ下したのかを説明できる必要があります。 例えば、Next.jsで個人ブログを作ったとき、ローカルの画像パスが見つからないという問題がありました。個人ブログなので、静的サイトにするほうが管理やコストの面で安かったんです。 そこで、ビルドの過程でマークダウンに書かれた画像パスから画像を探し、その画像をbase64にエンコードして静的なHTMLに埋め込む方法で解決しました。このように問題 → 制約 → 決定 → 結果の流れで話せる経験を、あらかじめ整理しておくといいです。 これに加えて、LeetCodeやHackerRankのようなサイトで定期的にコーディング問題を解くのも並行するといいですよ。 自分で答えてみたい面接の質問 実際の面接で受けたり、準備しながら集めたりした質問です。上の概念を整理したあと、声に出して答えてみてください。 ReactとNext.js Functional ComponentsとClass Componentsの違いを説明してください。 ReactのVirtual DOMは実際のDOMとどう違うのか、そしてなぜ重要なのかを説明してください。 Next.jsにおけるStatic GenerationとServer-side Renderingの違いは何ですか? Reactで状態管理のためにuseStateとuseEffectフックをどのように使いますか? Next.jsのgetStaticProps、getStaticPaths、getServerSidePropsの用途と違いを説明してください。 SEOとパフォーマンス Next.jsのpre-rendering機能はSEOにどんな利点をもたらしますか? Reactアプリケーションで動的コンテンツをSEOフレンドリーにするための戦略にはどんなものがありますか? Next.jsプロジェクトでメタタグとOpen Graphタグを動的に管理する方法を説明してください。 構造化データ(Structured Data)をReactまたはNext.jsアプリケーションに統合する方法と、その重要性を説明してください。 Next.js / Reactベースのプロダクトでページの読み込み速度を最適化する方法と、それがSEOに与える影響を説明してください。 Webパフォーマンス最適化のために使う方法とツールについて説明してください。 Webサイトの読み込みが遅くてユーザー満足度が下がっています。どう解決しますか? セキュリティとコラボレーション Webセキュリティの脆弱性と攻撃手法を知っていますか? それを防ぐためにどんな対策を取るべきですか? Webアプリケーションでユーザー認証と権限管理の機能を実装する方法を説明してください。 Webサイトがハッキング攻撃を受けたとき、どう対応すべきですか? 具体的な対応手順と予防策を説明してください。 複数の開発者が参加するフロントエンドプロジェクトで、効率的なバージョン管理とコードの共同作業のためにどんな方法を使いますか? 経験 最近進めたフロントエンド開発プロジェクトを紹介してください。目標、使った技術、主な課題と解決策、結果を詳しく説明してください。 レスポンシブWebデザインを実装するとき、どんな点を考慮すべきですか? 実際のプロジェクトで経験した事例を中心に答えてください。 さらに読んでおきたい資料 Webサイトを作ったら、Front-End Checklistで抜けがないか一度確認してみてください。そのほか、準備しながら参考にした資料です。ほとんどは韓国語で書かれています。 就職準備のために勉強した内容をまとめたリポジトリ F-Lab修了生の履歴書 自律的に働く組織のための就業規則の無料公開 バックエンド開発者の就職準備に関するすべて 就活生なら知っておきたいフロントエンド関連の知識 フロントエンド技術面接のためのハンドブック作り 現役開発者がまとめるフロントエンド新卒技術面接の問題集20選 実際に受けたフロントエンド開発者の面接質問まとめ 便利な機能を1行のコードで作ったJavaScriptユーティリティ すべてを一度に覚えようとするよりも、上のチェックリストの中で一文で説明できない概念から1つずつ埋めていくのが、いちばんいいスタートです。 All men who have achieved great things have been great dreamers.— Orison Marden

Claude CodeのようなAIコーディングエージェントを1つ使うのは、もう当たり前になってきましたよね。ところが、エージェントを複数立ち上げ始めると、すぐに壁にぶつかります。セッションが切れると進めていた作業が消えてしまい、誰が何をしているのかも見えないんです。 この問題に正面から取り組むオープンソースがいくつか出てきています。その中でGas Townがどんな構造でこの問題を解いているのかを見ながら、同じ系統のPaperclip、Vibe Kanban、Multicaとどこが違うのかを整理してみます。 Gas Townが狙っているもの Gas Townは、AIコーディングエージェント向けのマルチエージェント・オーケストレーションシステムです。エージェント1体ではなく、複数を同時に動かすことを前提に設計されています。 核となる思想はひとつです。エージェントが再起動しても作業状態を失わないようにすること。そのためにコンテキストをメモリではなくGitベースの永続ストレージに置き、これをHooksとBeadsという概念で扱います。 登場人物は4つ Gas Townの構造は、名前からして町のようです。役割は4つに分かれています。 Mayor（市長） — メインのAIコーディネーターです。人間はMayorと会話しながら作業を指示します。 Polecats — 実際に作業を行うワーカーエージェントです。 Hooks — Git Worktreeベースの永続的な作業ストレージです。エージェントの作業内容がここに残ります。 Convoy &x26; Beads — 個々の作業を状態追跡型データであるBeadsとして管理し、複数の作業をConvoyとして束ねて追跡します。 人間がワーカー1体1体に直接話しかけるのではなく、Mayorにだけ話しかけて、あとはMayorが自分で動かす構造です。 目を引く機能3つ 1) Git Worktreeベースの状態永続化 エージェントのセッションが切れたり再起動したりしても、進行中だった作業内容はGitベースの構造であるHooksに保存されています。だから立ち上げ直せば、やっていた作業をそのまま復元できます。 エージェントを複数回すときに一番痛いのがまさにここです。セッションが1つ切れるたびに最初から説明し直さなければならないなら、複数動かす意味がないですよね。 2) 大局的なコーディネーター、Mayor ユーザーがどのエージェントに何をさせるかをいちいち決める必要はありません。Mayorに全体の目標を渡せば、Mayorが配下のエージェントに作業を配ります。この配分の動作をGas TownではSlingと呼びます。 目標を投げる人と、仕事を分けて配るコーディネーターを分離したわけです。人間はPMの役割から一歩引くことができます。 3) TUIによる可視化とナッジ gt feedコマンドを打つと、数十体のエージェントが今どんな状態なのかをターミナルUIで一目で確認できます。状態はWorking、Stalled、Zombieといった形で区別されます。 止まっているエージェントが見えたら、ナッジ（Nudge）を送って再び動かすことができます。エージェントがループに陥ったり、死んだまま席だけ占めていたりするのを、人間が見つけてつつける窓口があるということです。 Paperclip、Vibe Kanban、Multicaと何が違うのか 似た問題を解くオープンソースは他にもあります。4つとも「エージェントを複数どう回すか」を扱っていますが、力を入れている場所が違います。 ツール 焦点 アプローチ Paperclip 組織統制 エージェントを「会社」と見なし、組織図、役割、予算統制、ポリシー管理に集中します Vibe Kanban カンバンとレビュー 人間の企画・レビューのボトルネックを解消し、Git Worktreeで作業を隔離してプレビューを提供します Gas Town セッション維持と自律的な配分 Mayorモデルで、メインAIが配下のAIを動かす階層型エージェント軍団の方式です Multica イシュートラッカーと作業キュー 人間とエージェントが同じイシューボードを使い、ローカルのデーモンがキューに積まれた作業を取って実行します Paperclipは誰が何をできるかを統制することに関心があります。Vibe Kanbanは人間がレビューする地点を快適にすることに集中しています。 Gas Townはその2つと違い、エージェント同士の階層を作ります。メインのAIコーディネーターが配下のAIを動かす方式なので、人間が介入する地点が一番上に置かれています。 Multicaはイシュートラッカーから出発します Multicaは「人間とAIエージェントが1つのチームとして働く」を掲げたオープンソースで、セルフホストが可能です。前の3つと違い、出発点がエージェントではなくイシュートラッカーです。 イシューに担当者を割り当てるようにエージェントをassigneeとして付けると、ローカルマシンで動くデーモンがキューに積まれた作業を取り、Claude Code、Codex、Gemini、CopilotといったCLIを実行します。結果はイシューのコメントとステータスとして残り、紐づいたGitHubのPRがマージされるとイシューは自動的にdoneに移ります。 エージェントを束ねてリーダーにルーティングするスクワッド、スケジュールやWebhookで作業を自動生成するオートパイロットもあります。Gas TownのMayorが会話の中で仕事を分けるのに対して、Multicaはイシューボードがそのまま作業キューなので、人間がいつでも同じ画面から割り込める構造です。 まとめ 4つのツールはそれぞれ違う軸を押さえています。Paperclipの組織的な統制力、Vibe Kanbanの視覚的なレビュー、Gas TownのMayorによる自動配分とヘルスチェックのロジック、そしてMulticaのイシュートラッカーベースの作業キューです。 マルチエージェントツールを選ぶときは、「どれが一番いいか」よりも自分がどの軸で一番困っているかを先に見るのがいいと思います。セッションが頻繁に切れて困っているならGas Townが解く問題とぴったり重なりますし、エージェントの作業をイシュー単位で残したいならMulticaのほうが近いです。 Don't settle for a relationship that won't let you be yourself.— Oprah Winfrey

エージェントで何か作ってみたくなると、たいていチャット画面ひとつに「これ作って」と投げますよね。企画も、画面も、コードも一度に出てきてほしい、という期待があるからです。 ただ、そうすると成果物がひと塊になって出てきて、どこを直すか以前に詰まってしまいます。エージェントで作りたいときに先に必要なのは、より賢いモデルではなく 役割が分かれたパイプラインです。 1つではなく、役割分担です 核心は、AIひとつに全部任せることではありません。企画、デザイン、開発、リサーチをそれぞれ別の役割にして、そのあいだを文書でつなぐオーケストレーションです。 役割が混ざると、成果物も混ざります。企画なのか実装なのか区別がつかないと、人はレビューする基準がなく、エージェントは次の段階へ渡す入力もなくなります。スピードと一貫性を同時に取るなら、先に役割を分ける必要があります。 必要な5つの役割 エージェントを何個も立ち上げる前に、下の5つの役割がそれぞれ 何を出力するのかから決めてみてください。 1) AI企画担当 問題をPRDとして固定する役割です。ユーザーストーリーと受け入れ基準（AC）を定義し、機能の優先順位も提案します。 ここで出た文書が、以降すべての段階の基準になります。チャット履歴が基準になってはいけません。 2) AI PM / タスクマネージャー PRDを実行可能な作業に分解する役割です。Epic → Story → Task に変換し、依存関係と順番を整理します。 人がいきなりコードを書かないようにして、先にタスク一覧を見るようにすることが大切です。大きな仕事を一度に任せると、脱線しやすくなります。 3) AIデザイナー 画面フローとワイヤーフレームを押さえ、コンポーネント仕様を整理したうえで、Figmaの草案を作ります。 デザインは画面全体を一枚で描くのではなく、コンポーネントからビューへ上がる方向で進めます。あとで開発者が組み立てる単位が、先に必要だからです。 4) AI開発者 イシューとデザイン仕様を入力にして実装します。コンポーネントを先に作り、そのあとスクリーンを組み合わせます。テストとリファクタリングもこの役割に含めます。 入力は「雰囲気」ではなく イシュー + コンポーネント + デザイン成果物である必要があります。入力が曖昧なら、実装も曖昧になります。 5) AIリサーチャー（インタビュー専門家） インタビューの質問を作り、その質問がなぜ必要なのか、正当性まで説明します。結果を要約してインサイトを抜き出し、次のサイクルへ渡します。 作ることの終わりはデプロイではありません。ユーザーフィードバックを次の入力に戻す役割が、パイプラインを閉じてくれます。 実行順序はこうつながります 役割だけ分けて同時に回すと、それぞれ違う前提を抱えた成果物が出てきます。順番が必要です。 問題定義 — 何を、誰のために作るのかを一行で固定します AI企画担当がPRDを作成 — ストーリーと受け入れ基準まで文書化します AI PMがタスク分解 — 実行単位と依存関係を整理します 人がレビューしてイシューを確定 — タスクを見てイシューに登録するのは人の仕事です AIデザイナーが草案を作成 — コンポーネント仕様と画面フローを作ります AI開発者が実装 — 確定したイシューとデザインでコードを積みます テスト、レビュー、デプロイ — 検証を通ったものだけ出します インタビューAIでフィードバック収集 — 質問と正当性、結果の要約を受け取ります 次のサイクルに反映 — インサイトを再び問題定義へ入れます この流れで人が抜けてはいけない地点は4番です。エージェントが作ったタスクをそのまま実装へ渡さず、イシューとして確定するゲートを人が握っている必要があります。 文書を単一ソースで維持します パイプラインが壊れるいちばん多い理由は、役割が多いことではなく、基準文書があちこちに散らばっていることです。 文書基準の単一ソース（SSOT）を維持します。PRDが変わったら、タスクもそれに合わせて変わる必要があります 各段階の成果物は リンクでつなぎます。PRD ↔ イシュー ↔ デザイン ↔ コードが互いに辿れる必要があります 人は 最終的な意思決定と品質判断を担当します。エージェントは草案と分解、実装を担います エージェントに任せるほど、人が記憶で調整してはいけません。次の役割が受け取る入力が文書とリンクでなければ、パイプラインは回りません。 まずは役割ひとつからです 最初から5つの役割を全部回す必要はありません。作りたいものがあるなら、今ひとつのチャットに混ざっている仕事を、役割の名前で分けてみるのがスタートです。 企画はPRDだけ、作業分解はタスクだけ、実装は確定したイシューだけを受け取るようにしてみてください。そのうえで、人がイシューを確定するゲートをひとつ入れるだけでも、「これ作って」の一発よりずっと扱いやすいパイプラインが生まれます。 No one can whistle a symphony. It takes a whole orchestra to play it.— H.E. Luccock