壁紙の一覧を読み込む画面を試作していた夜のことです。プレビューは問題なく開くのに、肝心の一覧だけが空っぽのままでした。赤いエラー画面は出ません。どこを直せばいいのか、手がかりがひとつもありませんでした。
私はそこで、「一覧が表示されません。直してください」と、ほとんど同じ文面を三回送ってしまいました。そのたびに「修正しました」という返事は返ってきます。けれども画面は変わりません。いま思えば、私は AI にも自分にも、見えていないものを直させようとしていたのだと思います。
最初にお伝えしたいのは、エラーの画面が出ない不具合は「壊れている」のではなく、「まだ見えていない」だけのことが多い、ということです。見えるようにする道具は、プロジェクトの中にすでにあります。
Logs パネルは、アプリが口にした言葉を並べた場所です
Rork のプロジェクトでは、画面の More → Code を開くと、ファイルの一覧とコードが出てきます。その下にあるのが Logs というパネルです。プレビューでアプリが動いているあいだに出力した内容が、リアルタイムで並びます。
行の頭には [log]、[info]、[warn]、[error]、[debug] のいずれかが付きます。古い行は上へスクロールすると読み込まれ、右端の矢印でパネルを畳むこともできます。公式ドキュメントでは、Code の画面はどのプランでも読めて、手で書き換えられるのは有料プランだけだと案内されています（Read the code and read the logs）。つまり、ログを読むだけなら無料のままでも足ります。
パネルが空のこともあります。「No logs yet. Logs from your app will appear here.」と表示されたら、故障ではありません。プレビューを実際に操作して、アプリに何かを出力させてください。画面を開いただけでは、何も並ばないことがあるのだそうです。
原因は、たいてい三か所のどれかです
個人開発のアプリで一覧が空になったとき、私自身は経路を次の三つに分けて考えるようにしています。
| 段階 | 何が起きているか | ログで確かめること |
|---|---|---|
| 1. 取りに行っていない | データを読む処理が呼ばれていない | 読み込みを始めた行が出ているか |
| 2. 取れたが中身が空 | 通信は成功しているが、返ってきた件数が 0 | 返ってきた件数と、通信の結果 |
| 3. 取れたが描かれない | 件数はあるのに、表示側の条件で隠れている | 表示の直前に、並べる件数を出す |
「直してください」とだけ頼むと、AI は三つのどれが原因なのかを知らないまま、いちばんありそうな場所を書き換えます。当たることもありますが、外れたときは「直したつもりの変更」だけが積み重なっていきます。
依頼文は「直して」ではなく「見せて」にします
そこで、修正を頼む前に、ログを出すことだけを頼みます。公式ドキュメントにも、エラー表示がないのに挙動がおかしいときは、まずログを頼むという例が載っています。私は次のような文面にしています。
一覧画面で、データを取りに行く処理の前後に確認用のログを足してください。
- 取得を始めたときに、1行
- 取得が終わったときに、通信の結果と返ってきた件数
- 画面に並べる直前の件数
コードの動きは変えず、ログの追加だけにしてください。「ログの追加だけ」と範囲を絞るのがこつです。範囲を決めておかないと、AI は親切心から周りの処理まで書き換えてしまい、原因の手がかりごと動いてしまうからです。
AI が足すログは、おおよそ次のような形になります。中身はプロジェクトの言語や構成で変わりますので、あくまで読むときの目安にしてください。
// 例: 読み込みの前後と、画面に渡す直前の件数を出す
console.log("[wallpapers] fetch start");
const res = await fetch(url);
console.log("[wallpapers] status", res.status); // 通信の結果
const items = await res.json();
console.log("[wallpapers] received", items.length); // 返ってきた件数
const visible = items.filter((i) => i.published);
console.log("[wallpapers] visible", visible.length); // 表示条件のあとの件数このコードを足す理由は、段階ごとに行が一本ずつ出るようにするためです。最後の二行の数字が received 24、visible 0 のように並べば、通信は成功していて、表示条件で全部が弾かれている、と読めます。数字は例です。
ログが出たら、行を読んで次の一手を決めます
プレビューを操作して問題を再現し、Logs を見ます。読み方は単純です。
fetch startが出ない: 段階 1 です。読み込みの処理がそもそも呼ばれていませんreceived 0が出る: 段階 2 です。画面ではなく、取りに行く先（URL・認証・サーバー側のデータ）を疑いますreceivedは正の数なのにvisible 0: 段階 3 です。絞り込みの条件を見直します[error]の行が出る: その行が、最初に貼る価値のある手がかりです
どの行が答えかを決めたら、その一行だけを依頼に貼ります。公式ドキュメントも、事実を渡すことを勧めています。「全文を貼る」より、「該当の行と、直したい範囲」を添えるほうが、AI が迷いにくいと感じています。
Logs に次の行が出ています。
[wallpapers] received 24
[wallpapers] visible 0
画面に渡す前の絞り込み条件だけを見直してください。他のファイルは変えないでください。通信まわりを深く調べたいときは、Rork でネットワーク通信・APIリクエストが失敗する時のデバッグガイドも参考になります。
貼る前に、ログに鍵が混ざっていないか見ます
ひとつだけ、貼る前の習慣があります。ログに認証用の文字列（トークンや API キー）が出力されていないかを、貼る前に目で追うことです。通信の結果をそのまま出す書き方をしていると、リクエストの中身が一緒に並ぶことがあります。
鍵らしき文字列があれば、伏せ字にしてから貼ります。そもそも鍵をコードに直書きしていないかは、別の記事で確かめる方法を書き残しました（Rork が書いたコードに鍵が直書きされていないか、40行ほどのスクリプトで一度だけ確かめます）。
赤いエラーが出ているなら、先にそちらを押します
ここまでは「エラーが出ない」場合の話です。プレビューに赤いエラーがはっきり出ているなら、ログを読むより先に、エラー表示の Fix with Rork を試してみてください。公式ドキュメントでも、見えるエラーがあるときはこの操作が案内されています。
それでも直らず、直したはずの変更だけが増えていくときは、一つ前の状態に戻すほうが早いことがあります。戻し方の選び方は、Rork で変更を戻すとき、Undo・Revert・メッセージの編集をどう選ぶかに整理してあります。
線引きは一文です
見えないものは、直してと頼む前に、見えるようにします。
あの夜の一覧は、結局、表示条件の見落としでした。ログに received と visible の二つの数字が並んだ瞬間、三回の「直してください」が何だったのかが一気に分かって、肩の力が抜けたのを覚えています。
次に画面が空になったときは、修正を頼む前に、「取得した件数と、画面に渡す前の件数をログに出してください」と一文だけ送ってみていただければと思います。私もそこから始めるようにしています。