GPT5.3 Codex を使用してバーンアウトとボーアウトチェックツールを作ってみる
はじめに
このドキュメントはGPT5.3 Codexを試した備忘録です。
VSCode + GPT5.3 CodexでJavaScriptのコードがどの程度うまく作成されるかを試すものになります。
今回はGPT5.3 Codexでバーンアウト、ボーアウトのセルフチェック行うWebアプリを作成します。
このアプリは10年前のjQueryとかで動いていたものをReactに移植したものになります。
バーンアウトとボーアウト
バーンアウト(burnout,燃え尽き症候群）とは、今まで普通に仕事をしていた人が、急に、あたかも「燃え尽きたように」意欲を失い、働かなくなるケースのことです。
逆に、ボーアウト(Boreout)とは仕事に退屈しきっている状態を指します。能力以下の仕事しか与えられず、仕事に関心を失い、職に就いていながら、いわばニートのような状況にいることであり「社内ニート症候群」ともいえます。
バーンアウトとボーアウトは対極の関係にあります。
仕事量が一定の範囲を超えた場合、バーンアウトの発生リスクが生じ、仕事量が一定の範囲を下回った場合にボーアウトの発生リスクが生じると考えられます。
バーンアウトにせよ、ボーアウトにせよ離職、転職等の人的リソースの損失になります。
GPT Codexの導入方法
VSCodeのプラグインとして導入できます。
MacOSの場合はアプリがサポートされているようですが、Intel CPUの場合はインストールできなかったです。
今回はWindows11 + VSCodeで実験することにします。
Codexのページにアクセス後、IDEで試すを実行します。
VSCodeが開きます。
拡張機能のインストールを行います。
左側にCodexのアイコンが表示されます。
Sign in with ChatGPTを押下してブラウザでログインします。
ログインが行われると画面が変わるのでNextを押し続けます。
チャットができるようになります。
実験内容
以下のフォルダにあるjQueryで書かれたコードをReactなどのモダンな環境に書き直す実験をします。
モダンな環境に移植する
jQueryなどで書かれていたコードをvite+Reactに書き直します。
使用したプロンプトは次の通りです。
mentaltestフォルダにはバーンアウトとボーアウトを計測するページがあります。これをReact＋Viteを使ってモダンなページに直したいです。codexフォルダにnode.jsでビルドできる環境を構築してください
このプロンプトを実施するとpackage.jsonなどを作成してvite + Reactの空のプロジェクトが作成されました。
依頼の意図としては移植まで依頼したつもりでしたが、プロジェクトのテンプレート時点で一回とまりました。
念のためどういう意図か確認をします。
あなたが今やったことはvite+reactのテンプレートを作っただけという理解でいいですか？
ここで以下の回答を得ました。
はい、その理解で正しいです。
今回やったのは codex に Vite + React の初期テンプレートを作成し、npm install と npm run build が通ることを確認したところまでです。mentaltest の内容移植やデザイン改修はまだ未着手です。
そこで、移植をお願いするプロンプトを実行します。
burnout.html と boreout.html の設問ロジックを React コンポーネント化
base.css をベースにモダンUIへ再設計（レスポンシブ対応）してください。
このプロンプトの結果以下のファイルが更新されました。
- App.jsx
- App.css
- index.css
この時点で画面動作的にはそれっぽい移植された画面ができ、それっぽく動作します。
とはいえ、App.jsxにすべてが記述されている状態だったので、次の依頼をしました。
一つの大きなファイルで作るのでなくてコンポーネントに適切に分割できませんか？
この結果、以下のファイルに分割されます。
- App.jsx
- Hero.jsx
- TestSwitcher.jsx
- QuestionList.jsx
- ResultGrid.jsx
- mentalTests.js
- scoring.js
ここまでの結果は以下で確認できます。
TypeScript対応
JavaScriptだと型が不安定なのでTypeScriptに直してもらうようにお願いしました。
現在はjavascriptでの実装ですが型が不安です。typescriptにしてください。
このプロンプトは特に問題なく実行されてTypeScriptに変換されました。
ここまでの結果は以下で確認できます。
単体テスト対応
単体テストの作成をするために以下のプロンプトを実行しました。
単体テストのコードを追記してもらっていいですか？vitestでお願いします。
するとテストコードを「テスト対象の近くに置く（co-located）」構成で作成しようとしました。
今回はフォルダを分けたいため処理を中断して以下のプロンプトを実行しました。
testsフォルダに分離する方向でテストコードを書いてください。
結果として以下のテストコードが作成されました。
- mentalTests.test.ts
- scoring.test.ts
プロダクトコードに比べてテストコードが少ないように感じたのでカバレッジを計測するように依頼しました。
カバレッジの計測をするようにしてください。
package.jsonが更新されて、npm run test:coverageでカバレッジ計測をした単体テストが実行できるようになりました。
カバレッジを確認すると、mentalTests.tsのカバレッジが非常に低いためテストの追加を依頼しました。
現在mentalTests.tsのカバレッジが非常に低いです。テストコードを修正してください。
mentalTests.test.tsにテストケースが追加されました。
最後にeslintで複雑度のチェックをしていなかったようなので、その追加を依頼しました。
複雑度についてエラーを出すようにしてください。
これによりあまりに複雑なコードについてはlint実行時にエラーが通知されます。
ここまでの修正は以下で確認できます。
カバレッジの改善
この時点ではプロダクトコードに比べてテストコードがあきらかに足りていないのにカバレッジが100%となっていました。
そこで次のように問い合わせました。
カバレッジが100%にみえますが、これはcomponentsフォルダとかを参照していないようにみえますが
この回答としては次の通りとなりました。
その通りです。今の 100% は「テストで読み込まれたファイルだけ」の結果です。
現状は data と utils しかテスト対象にしていないので、components は母集団に入っていません。正しく全体を見るには、Vitest で coverage.all: true と coverage.include を設定します。例:
*.{ts,tsx} を対象
main.tsx や vite-env.d.ts は除外
必要ならこの設定を追加して、components を含めた実カバレッジを出します。
そこでsrcフォルダ中のプロダクトコードすべてでカバレッジを計測したいため、以下の依頼を実行します。
srcフォルダ中のコードが書かれるファイル全てを対象にしてもらっていいですか？
この結果vite.config.tsが更新されました。
この状態でカバレッジを計測すると、componentsフォルダが一切テストされていないことが確認できました。
そこで次のように依頼します。
src/componentsにあるtsxを対象としたテストを書いてください。
この結果、以下の変更が発生しました。
-
追加したテスト:
- Hero.test.tsx
- TestSwitcher.test.tsx
- QuestionList.test.tsx
- ResultGrid.test.tsx
-
追加/変更:
- setup.ts（@testing-library/jest-dom/vitest 読み込み）
- vite.config.ts
-
依存追加（devDependencies）
- @testing-library/react
- @testing-library/jest-dom
- jsdom
App.tsxとmain.tsxのテストは作られていないようのでさらに追加の作業を依頼します。
App.tsxとmain.tsxのテストも書いてください
- 追加ファイル:
- App.test.tsx
- main.test.tsx
- 修正ファイル:
- setup.ts
カバレッジレポートを確認すると、テスト漏れが存在しています。そこで修正を依頼します。
TestSwitcherのonClickをチェックするテストが存在しないようです。
- 修正ファイル
- TestSwitcher.test.tsx
ここでテストコードのカバレッジは100%になりました。しかし、npm run buildは失敗します。
npm run build は正常終了しますか？修正してください。
この結果無事、テストも動くし、ビルドもできるコードが作成されました。
履歴機能の追加
過去のチェック結果をローカルストレージに保存して確認できるようにします。
まず、ボタンを押したらチェックをするように修正します。
結果の表示については移植元と同じようにボタンを押したら表示されるようにしてください
以下の修正がおこなわれました。
- App.tsx
- 自動表示を廃止
- 判定する ボタン押下時にだけ結果を計算・表示
- バーンアウト/ボーアウトそれぞれで独立して判定実行
- App.css
- 判定ボタン用スタイルを追加（.action-row, .calculate-button）
- App.test.tsx
- 新挙動に合わせて更新
- ボタン押下前は結果非表示、押下後に表示されることを検証
次に判定ボタン押下時にローカルストレージに履歴を保存するように依頼します。
判定するを押下した場合にローカルストレージに回答内容とスコアを保存しておき、過去100回までの結果を履歴として振り返るようにできませんか？
この修正ではバーンアウト、ボーアウトの履歴がまとめて表示されるようなコードが提案されました。
そこで次のように修正を依頼します
バーンアウトとボーアウトの履歴はそれぞれ別に100件保持して、別々に表示してください。また、履歴の削除ボタンを用意してください。
この修正だとたしかに履歴が別々に表示されるようにはなりましたが、タブで切り替わるような意図した挙動になっていませんでした。そこでさらに修正を依頼します。
履歴の表示の仕方について、バーンアウトタブを選択しているときはバーンアウト履歴のみ、ボーアウトタブを選択しているときはボーアウトの履歴のみとしてください。
この依頼により次のような挙動になりました。
- バーンアウトタブ選択時:
- バーンアウト履歴（最新100件） のみ表示
- 削除ボタンはバーンアウト履歴のみ対象
- ボーアウトタブ選択時:
- ボーアウト履歴（最新100件） のみ表示
- 削除ボタンはボーアウト履歴のみ対象
画面の動きについては適切なようにみえますが、テストコードのカバレッジは低かったため、テストコードの追記を依頼します
history.tsとApp.tsxについて網羅していない分岐があります。
この修正によりテストコードがカバレッジを満たしました。
ここの修正内容は以下のPullRequestで確認できます。
このPullRequest中にGitHubCopilotで指摘された内容をCodexに張り付けて修正を実施しています。
スコアのグラフ化
過去のスコアについてグラフ化する修正を依頼しました。
次の機能追加をお願いします。履歴がある場合、デフォルトの回答は最後の履歴のものを利用する。 履歴がある場合、点数についてグラフで表示する
この修正では棒グラフを追加されました。線グラフが欲しかったため次の依頼をします。App.tsxにべた書きしているため、それの改善も依頼します。
グラフは折れ線グラフにしてください。また、App.tsxが肥大化しすぎです。履歴関係をコンポーネントで切り分けてください。
この依頼でたしかに線グラフになりました。
しかし、バーンアウトのスコアについて３つの項目の合計でグラフ化しています。
そこで以下のように修正を依頼しました。
バーンアウトについてスコアをまとめて表示されても意味がありません。情緒的消耗感、脱人格化、個人的達成感を分かるように表示してください。
この指示では以下のようなグラフになり正常とはいえない状況でした。
画像を張り付けて以下の指示を実施しました。
適切なグラフとはいえません。また、凡例も同じ色にみえます。
凡例はなおりましたがグラフの表示はやはり異常です。
塗りつぶしはなおっていません。
この指示により修正がおこなわれました。
その後、テストカバレッジが低いため修正を依頼しましたが、これには時間がかかりました。
テストを追加しようとせず、プロダクトコードを突然直しはじめたのでいったんとめて意図を確認したり、未到達コードのひとつづつにたいしてなぜ未到達なのかを確認するようなプロンプトを投げて、カバレッジを100%にした後のプルリクエストが以下になります。
所感
今回はGPT5.3 Codexに実装のすべてまかせてみました。
たしかにやることが明確なものについては、かなりの性能をみせます。
たとえば、元になるコードを移植するとか、TypeScript対応しろとかというのは手がかからず実施できました。
一方、すべてまかせるというのは危険に感じました。たとえばテストコードはカバレッジを意識しませんし、１ファイルにすべてを書いたり保守性についてあまり考慮されない実装になっています。
また、テストコードで動作を確認できるものについては、ある程度自己解決がおこなえますが、グラフなどの画面の表示確認などをともなうコードについては人間の補助が必要に感じます。
なお、今回のCodexが行った修正のプルリクエストについてはGitHubCopilotでちょくちょく問題を指摘されていたので、別の静的解析ツールやレビューAIを併用した方が安全だと感じました。
どう作ればいいか知っている人間が使う分には大きな武器になりそうですが、どう作っていいかわからない人間が使う場合はおそらくうまくいかないかと思います。
Discussion