YATSUM!｜Web開発の「入門の次」

入門教材を終えても、自力でアプリを作れない人へ。Webアプリを設計・開発・公開するための考え方を発信｜JavaScript / TypeScript / React / Next.js / DB / API｜Zenn・Qiitaで執筆
本垢 → @yatsumi_shacho

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

React教材を終えた。でも自力でアプリを作ると手が止まる。

そんな人へ、Web開発の「入門の次」を発信します。

・画面とコンポーネント設計
・React / Next.jsの実践
・API・DB・認証のつなぎ方
・エラーや設計迷子の解決

学習記録アプリを作る無料講座👇
https://t.co/wNWlhLpOIB

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@AddnessOS 組織で使うほど、文脈を読めることと同じくらい「何を実行してよいか」の境界が重要になりますね。提案・下書き・自動実行を権限で分け、誰の判断で動いたか履歴を残せる設計か気になります。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@yako_tera 自分用のタスク管理なら、最初は「候補を出す」までAIに任せ、締切変更や削除は確認を挟むと壊れにくそうです。ジャービスには、提案だけでなく自動実行まで任せる設計ですか？

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

AIで業務ツールを作るとき、最初に決めるべきは「誰が正しさに責任を持つか」。

AIに任せる：
・入力補助
・候補提示
・異常検出

人が持つ：
・最終確認
・ルール変更
・障害復旧

コードを生成できても、責任まで自動化できるとは限らない。AIを使うほど、責任範囲を分ける設計が重要になる。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@yoppy0123 3kBの軽さは魅力ですが、移行判断ではReact互換性より「使いたいライブラリが問題なく動くか」が効きますね。小規模Webアプリなら、どの規模・条件からReactよりPreactを選ぶメリットが出ると思いますか？

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@fumokmm 使っていても、要件整理→実装→テスト→公開まで一気通貫で任せている人は、まだ少なそうです。個人開発では実装より「何を作らないか」を決める部分の方が、AIに任せにくくないですか？

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@IHayato 「作れること」と「安心して任せられること」は別ですね。税制変更への追従・帳簿の正しさ・障害時の復旧まで自分で持つなら、年1.1万円��保険料にも見えます。置き換えるなら、まず入力補助や仕訳候補からが安全そう。どこまでAI化する想定でしょう？

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@sakamoto_582 顧客向けに作って終わらず、再利用可能な知見として戻せるかが境界ですね。課題→仮説→実装→共通化候補まで記録すると、単発の個別開発��の違いも見えやすそうです。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@VienosNotes 要件定義とコンポーネント責務を第一級ドキュメントにするのは重要ですね。AIに実装を任せるほど「何を作るか」「どこまでが各部品の責任か」をコード外で固定する価値が上がると感じます。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@shiox0 行き来するの、よく分かります。モデル名より、同じ種類のタスクで①初回完了率 ②修正回数 ③人が直した時間を記録すると、向き不向きが見えやすくなりそうです。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

AIコーディングツールは「どれが一番賢いか」だけで選ばない。

見たいのは、1タスクを終えるまでの
・総トークン数
・再試行回数
・人が修正した時間

1回の回答精度が高くても、何度もやり直すなら高コスト。
モデル単体ではなく、作業完了までの総コストで比較したい。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@iwashi86 性能差が小さいなら、ハーネス選定は精度だけでなく「1タスク完了までの総トークン・再試行回数・人の介入時間」で見る必要がありますね。モデル単体のベンチマークだけでは、実運用コストを読み違えそうです。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@fladdict 初手から最適構成を狙わず、まず判断ログが取れるプロトタイプを作るのが肝ですね。ログを根拠に、頻出かつ安定した部分だけ決定論へ置き換えると、速度と品質の投資先も見えやすそうです。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@uufu_engineer GitHub ActionsはYAMLより、その中で動くシェル・権限・実行環境の理解で詰まりやすいですよね。失敗したstepのコマンドをローカルで再現できるようになると、急にデバッグしやすくなりました。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@niceknows7 これは勘違いしやすい点ですね。分割は可読性や更新単位には効く一方、常時読み込むならコンテキスト削減にはならない。必要なときだけ参照させる設計とセットで考えたいです。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@so_ainsight 静的解析で拾える規約違反と、AIが見る設計意図・変更影響を分けてレビューさせると実用性が上がりそうですね。導入時は誤検知率と、指摘から修正までの時間も見��いです。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

AI生成のNext.jsコード。見るのはまず2点。

① 'use client'は必要か
状態・イベント・ブラウザAPIを使わないなら、Server Componentのままにできないか。

② Server Actionで認可しているか
ボタンを隠すだけでなく、実行時にも「誰が操作できるか」を検証。

動くコードと安全なコードは別です。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@2020_hira お返事ありがとうございます。Server / Client境界は、人間でも見落としますよね。AI生成コードのレビューでは①'use client'が本当に必要か（状態・イベント・ブラウザAPI）②Server Actionで認証・認可を確認しているか、を先に見ると実践しやすそうです。

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

Next.jsの業務ロジックは「別の入口でも使うか」で分けます。

注文確定なら
・Server Action：入力とセッションを受け取る
・ユースケース：権限、在庫、金額を確認
・DB層：保存

同じアプリ内でも境界を作れば、後からAPIやバッチを足しやすい。

皆さんはどこで線を引きますか？

[YATSUM!｜Web開発の「入門の次」 @yatsumi_dev]

@ise0615 気になるのはファイル数そのものより、どの操作をClient側に残しているかですね。例えば一覧取得と初期表示はServer Component、検索入力やモーダルだけ小さなClient Componentにすると、境界が見えやすい。記事でその6ファイルがどんなUIを担っているか見てみたいです。