３万払ってcodexで遊んでる フォルダ機能実装編

前回

今回

この左側の保存したリクエスト共を

これにしていく

機能として大きく、codexでやらせても比較して実装に時間がかかっているので別記事となってます。
小さな新規機能の実装の感想は前回を更新しようと思っています。

前書き

今回の人間の感想は生成AIを使わず、codexを利用している際に思ったことをなるべく書いていきます。
人間なので抜けもあると思います。

要件定義

結構でかい機能です。
前回のように雑なお願いをすると間違いなく作成仕切れないことがわかっています。

要件定義スタート

実はフォルダ機能って何気なく使ってますが、仕様に落とすと馬鹿みたいにでかい機能だということがわかります。
人間の手で仕様書を書き出すと大変なのでo3にお願いします。
https://chatgpt.com/share/682ff073-035c-800f-b2ff-7deb9bcf39cf

仕様をまとめさせているとこれcodex実装無理だなってのが直感でわかります。
っていうか人間がやってもかなりしんどいです。
ライブラリを利用することを検討します。
https://chatgpt.com/share/682ff0ce-3208-800f-bbf3-ca2e488e571c

ライブラリの選定をさせ、提案されたライブラリを人間が確認し選択、最終的に出来上がったのが以下の仕様となります。

# フォルダ機能 仕様書 (v0.5)

## 1. 基本要件
| 機能 | 詳細 |
|---|---|
| **フォルダ作成ボタン** | サイドバー上部に常設（＋アイコン）。クリックで「新規フォルダ」を生成。 |
| **コンテキストメニュー** | フォルダを右クリック → 小型メニュー表示（既存リクエストの右クリックメニューを流用）。<br>メニュー項目: <br>&nbsp;&nbsp;• 新規フォルダを作成<br>&nbsp;&nbsp;• 新規リクエストを作成<br>&nbsp;&nbsp;• フォルダの名前を変更<br>&nbsp;&nbsp;• フォルダを削除 |
| **トグル表示** | フォルダクリックで配下リクエスト一覧を展開／折りたたみ。インジケータ（▶ / ▼）付き。 |
| **並び順** | 同一階層内で「フォルダ → リクエスト」の順、かつ名前昇順（大文字小文字を区別しない、Unicode 正規化）。 |
| **削除時の挙動** | フォルダ削除は **再帰的削除**（配下のサブフォルダ・リクエストも全削除）。確認ダイアログ必須。Undo は 1 ステップ分サポート。 |
| **サブフォルダ深さ** | **無制限**（階層制限なし）。 |
| **アクセシビリティ & キーボード操作** | **ARIA TreeView 準拠**。キーボード操作必須：↑ / ↓ / ← / → / Enter でフォーカス移動・展開／折りたたみ・選択が可能。 |

---

## 2. ドラッグ＆ドロップ (DnD) 詳細仕様

| 項目 | 仕様 |
|---|---|
| **ライブラリ** | [`react-arborist`](https://github.com/brimdata/react-arborist) （組み込み DnD + 仮想リスト + ツリーモデル） |
| **ドラッグ可能要素** | フォルダ・リクエストの両方 <br>— ただし **ドロップ受け入れ先はフォルダのみ** |
| **禁止ルール** | - フォルダを自身またはその子孫へドロップ不可<br>- リクエストをリクエストへドロップ不可 |
| **順序変更** | 同一フォルダ内で上下並び替えは標準ドラッグ操作で対応（`onMove` が移動結果を返す） |
| **入れ子変更** | ドロップ位置がフォルダのヘッダ上の場合、そのフォルダ配下に移動。<br>階層は無制限だが禁止ルールの循環チェックを行う。 |
| **自動展開** | ドラッグオーバー中に 500 ms ホバーでフォルダを自動展開 (`setTimeout`) |
| **ビジュアルフィードバック** | - ドラッグ中のアイテムは `opacity: 0.7` + 軽い `box-shadow`<br>- ドロップターゲットは `outline: 2px dashed`<br>- 挿入位置は 2 px ラインインジケータ |
| **オートスクロール** | react-arborist 標準の auto‑scroll 機能を使用（追加実装不要） |
| **アニメーション** | react‑arborist の既定（react‑spring, 120 ms ease‑out） |
| **パフォーマンス** | 仮想リスト機能が標準搭載。要素数 5,000+ でも安定。 |
| **アクセシビリティ** | キーボード DnD は **非対応**。マウス／タッチ操作のみ。 |

---

## 3. 補足
- **永続化方式** は既定のストレージ戦略に従う（詳細割愛）。
- 大量データバーチャライズは scope 外。必要になれば別途検討。
- 保存済みリストのStyleもTreeの表示に合わせて修正する。

---

*最終確認後、実装フェーズへ進んでください。*

codexに丸投げしよう

投げてみました。

実際のプロンプト

• 人間のミスでお願いした内容をアーカイブしてしまいました
• リンクが見当たりません
  • 結構必死に探してるんですが、これのお願いがあまりにもうまくいかないことが多く、似たようなアーカイブが多すぎて探すのに苦労しています
    
• 見つかり次第の更新とさせてください

やらせている時の感想

• 実際にやらせてみるとわかるんですが、デカすぎる機能をお願いすると全て実装しきれずに度々止まります
• 多分ランタイム制限がかかってます
  • ただ、途中人間の確認がないと迷走するので止まって欲しいと思ってます
  • ちょうどいいくらいで止まってるなと感じます
• ライブラリの仕様を仕様書にて指定していますが、遵守していないことがログからわかりました
  • 仕様を丸っと投げるのではなく、細かく指示を与えるほうがいいことを再認識できます
    • でもこれ仕様丸っと渡した上で考慮しながら作って欲しい内容になります
    • どこまで渡すかが難しい
      • 今思うと「確認を求める」の方で動かせばタスクを細分化しうまく動くのでは？
        • また今度やらせてみます

ある程度できた段階で次のプロンプトに引き継いだ

• https://chatgpt.com/codex/tasks/task_e_682f7372f5e8832fb29304a6110fab2e
• 仕様書を渡して何が足りていないかを確認した上でタスクの提案を依頼しています
  • 完璧には確認しきれていないことが最初のやりとりでわかります
  • 大きな修正は「確認を求める」を利用してタスク分解と整理を手伝い、ハンドリングしてやることで精度が上がりそうです
  • ここまで指示を出せばある程度満足する実装になりました

完璧ではないところ

• 画像を見るとわかりますが、1pxの隙間があります
  
  ただし下側にはありません。
  

• つまりitem-centerがうまく動作していないことがわかります

  • でもこれをテストコードに落とし込むことも面倒ですし、codexはここまで考慮してくれません
    • もしかしたらお願いの仕方次第かもしれません
  • ただ、こういう微細な修正は人間の手でやる方が早くなりそうです

---

• 仕様をある程度妥協した方がいい

  • かなり賢いですが、完璧かと言われると難しいです

  • フォルダのリネーム処理について以下の画像のような形に妥協しています

  • 

    • 右クリックでメニューが開き、「フォルダリネーム」を選択するとリネームモーダルが開くという仕様です

  • VSCodeのようなリネームを目指していましたが、テキスト入力時に問題が起きていました

    • 多分これと同じ現象です
    • https://zenn.dev/itmaroon/articles/6ece2f91f6f4c0
      • この記事でもchatGPTの答えがイケてないということが言及されています

  • ライブラリの調査をo3に行わせながら人間が引き継いでインラインリネームが実装されました

    • プログラマー不要論はもうちょっと先になりそうです
      

---

• 他にも結構微細なところで問題が起きてました
  • 上記のモーダル式に変えてもらいました
    • しかしcodexはformで実装しませんでした
      • そのため、一般的に期待するenterを押したら名前の変更が発火されるという動作が実装されていませんでした
      • 妥協しても人間の手が多少必要ということがわかります

ここまで色々やってみての感想

いつも言われてるような話題の感想を書いたり、
codex使う上でこれは意識が必要だなーと思ったことを書きます。

今回の反省点や感想、エージェントを使う上で気をつけたいこと等

• プロンプトはある程度で詠唱破棄しよう（N回目）
  • フォルダ機能は大きい機能で、あらかじめ色々言いたくなる機能だった
    • でもライブラリ使うって方針に出来てるならもう少し細かい単位とすることが出来たよねって話があった
      • ぶっちゃけライブラリが備えてる物で要件のほぼ全てを満たせてた
        • ライブラリを正しく使ってくださいだけでよかったなーと思った

---

• 既存のプログラムを正とみなす傾向がかなり高い
  • なので混乱させないために質の低いコードは直していくことが必要になる
    • 人間の審美眼が必要
      • 前述の通り、AIは現状が正しいものと思い込む傾向が強いので、それにはっきりNOと言える人間は大事
    • 生成AIを使うことで浮いた工数は生成AIが動きやすい環境整備に使いたいなと思った
      • 人間によるリファクタリングはAIの福利厚生になる

---

• テストコードはやっぱり大事
  • これがあると非常に迷走しにくくなる
  • TDDの時代が来た

---

• 結局プログラマーは不要か
  • 今の所まだNOとはっきり言える
  • まぁでも簡単な要件なら不要になるかも
    • ならんかも
  • 非IT系の人と接触する機会を持ってる一応IT系の人間からみると、非IT系の人間が使うのはまだ難しいと思う
    • 結局ある程度プログラムとは何かがわかってないと使えない
      • 非IT系の人からするとただのマクロでも魔法みたいなもんという話がある
    • そもそもの要件定義すら怪しい人が非ITにはいる
      • IT業界にもいる
    • かなり魔法に近いが、一応魔法ではないし魔法の国にも魔法が使えない人はいる
      • まぁでも専門家としては今後は魔法から工学に変えていけるようにしたいね

他の人と似たような感想や結論になってる。
そんなもんです。
生成AIを使いこなせる側になりたいね。
そういえば牛本出ましたよ。
みなさん買った方がいいです。