PythonのFletで進めるか、Dartを使うか迷った話
前回の作業で、過去の記事データや設定をデータベースへ移すところまでは終わりました。
いよいよ画面を作っていこうと思ったのですが、
自分で少し調べているうちに、気になる話を目にしました。
今回はPythonとFletを使って画面を作る予定なのですが、
「Fletと、その元になっているFlutterを同じものとして扱ってはいけない」
という意見を見かけたのです。
自分で調べてわかった範囲でも、
本来のFlutterはDartという言語とセットで使うもので、
Fletだと本来のFlutterでできることに色々と制限がつくらしい、
ということがわかってきました。
そこで、作業を進める前にいくつか気になっていたことを、
AIの会議システムを使って調べてもらうことにしました。
AIがコードを書く前提での言語選び
私が気になっていたのは、次のような点です。
・今からでもDartを使った方がメリットがあるのか
・いずれ機械学習なども触ってみたい場合、どういう組み合わせになるのか
・私はGoogleのサブスク（Google AI Ultra）に入っており、
今後Google製のツール同士の連携が強まるなら、
Googleが出しているDartを使える方が有利なのではないか
・自分でコードを書くわけではなく、Antigravityにコードを書いてもらう前提なので、
人間にとっての勉強のしやすさではなく「AIが扱いやすいかどうか」が大事なのではないか
こうした疑問をぶつけてみたところ、
Googleの中でも役割がはっきり分かれているという話が返ってきました。
画面やスマホアプリを作る部分ではDart（Flutter）が推進されていますが、
AIや機械学習、裏側のデータ処理に関しては、
Google社内でもPythonが中心として使われているそうです。
また、AI自身がコードを書く場合でも、
世の中に圧倒的に多くのサンプルがあるPythonの方が、
より正確にコードを書けるとのことでした。
PythonとDartを自分で組み合わせるのは大変
その説明を聞いて、ふと一つの疑問が浮かびました。
「画面として表示する直前までの処理を全部Pythonで書いて、
最後の画面表示だけをDartとFlutterに任せる形にすれば、
いろんなことに対応しやすいのではないか」と思ったのです。
しかし、これも聞いてみると、
「まさにその仕組みを裏側で自動的にやってくれているのがFletそのもの」
だという答えが返ってきました。
もしFletを使わずに、自分でPythonとDartを別々に作って繋ごうとすると、
2つの言語の間でデータをやり取りするための通信の仕組みを自作しなければなりません。
しかも、画面を閉じた時に裏側のPythonがうまく終了せず、
見えないところでプログラムが動き続けてしまう問題も起きやすいそうです。
前に作った自作ダッシュボードで裏側の通信まわりには散々苦労したので、
余計な仕組みは増やさず、このままPythonとFletで進めることにしました。
ちなみに、Flet用の拡張ツール（MCP）を入れた方がいいかも聞いてみましたが、
使う画面パーツは基本的なものばかりなので、管理の手間を増やさないためにも入れなくて大丈夫とのことでした。
---
ブログ管理ツールの画面設計とデザインの悩み
方針が固まったので、次は画面の設計に入りました。
ツールの名前は、自分一人で使うものなので、シンプルに「ブログ管理ツール」のような分かりやすい名前を付けることにしました。
画面を作るにあたって悩んでいたのが、デザインと機能追加の順番です。
以前ツールを使っていた時から、
「もっとこういう機能も欲しいな」と思っていたものがいくつかありました。
ただ、最初から新しい機能を詰め込むと、
うまく動かなかった時に原因がわからなくなりそうだったので、
まずは元の機能をそのまま再現してから、後で少しずつ直していく流れが良いか確認しました。
AIからも「まずは元の環境を再現するのが一番確実」と背中を押されたので、
機能はこれまでの流れを維持することにしました。
もう一つの悩みは見た目です。
個人的にグラスモーフィズム（すりガラスのような半透明のデザイン）が好きなのですが、
ブログを書くツールにそういうデザインは合っていない気もしていました。
それでもやっぱり一度作ってみたいという気持ちがあり、正直に相談してみました。
すると、暗い背景をベースにしたダーク・グラスモーフィズムにすれば、
長時間の作業でも目が疲れにくく、文字も読みやすいという提案がありました。
ただし、事前のリスク検証をしてもらったところ、
本物のすりガラス効果（リアルタイムのぼかし処理）を画面全体に使うと、
文字を1文字打つたびに計算が走ってしまい、
文字入力が重くなる原因になることがわかりました。
そこで、見た目はすりガラス風の半透明の色合いにしつつ、
実際の文字入力エリアは重くならないように不透明にするという、
実用性を優先した作りで実装してもらいました。
---
起動してみたらエラーが連続で出た
AIがブログ管理ツールのコードを一通り書き終えたので、さっそく手元の環境で動かしてみました。
ところが、起動した瞬間にエラーが出て止まってしまいました。
最初に出たのは、`module 'flet' has no attribute 'app'` というエラーでした。
エラー文をそのまま貼り付けて見てもらうと、
原因は私のパソコンに入っていたFletのバージョンが、
新しいFlet 1.0.3だったことにあるとわかりました。
AIが持っていた知識は少し前のバージョン（0.x系）のものだったため、
起動するための命令である `ft.app()` が、
新しいバージョンでは `ft.run()` に変わっていることを知らずに書いていたのです。
直しても別のエラーが出るイタチごっこ
そこを直してもらって再度起動すると、画面は立ち上がったものの、
今度は画面上に赤いエラーメッセージが表示されました。
`FilledButton.__init__() got an unexpected keyword argument 'text'`
これも同じ原因で、ボタンの文字を指定する書き方が、
新しいバージョンでは変わっていたために起きたエラーでした。
AIの学習データが古いためにエラーが出る問題は、
他のプロジェクトを触っている時にもよく起きていました。
そのため、ここで一度AIに対して、
「コードを書く時は必ず公式の仕様や実際のファイルを確認すること」
「推測でコードを書かないこと」をルールとして徹底するように伝えました。
しかし、その修正の後にもう一度動かしてみると、
今度は枠線を作る部分でまた別のエラーが出ました。
`module 'flet.controls.border' has no attribute 'all'`
一つ直しては次のエラーが出る状態だったので、
「実際に起動してエラーが出ないこと、
作ったはずのボタンや機能がすべてちゃんと動くところまで、
自分で動かしてテストと修正を行ってください」とお願いし、
徹底的に洗い出してもらうことにしました。
---
解決の糸口と今日の学び
最終的に、パソコンの中にインストールされているFlet本体のプログラムファイルを、
AIに直接隅々まで読み込ませることで、ようやくすべてのエラーが解消されました。
今回のFlet 1.0へのバージョンアップでは、
かなり広い範囲で書き方のルールが変わっていたようです。
・アプリの起動方法が `ft.app` から `ft.run` に変わった
・枠線や余白の指定が `ft.border`（小文字）から `ft.Border`（大文字始まりのクラス）に変わった
・ドロップダウンの選択イベントが `on_change` から `on_select` に変わった
こうした細かい変更がいくつも重なっていたため、
AIが過去の記憶だけで書くと、どうしても古い書き方が混ざってしまっていたようでした。
今回の作業を通して学んだのは、次の3点です。
・AIは新しいバージョンの仕様を知らないことがある
特に大きなバージョンアップがあったばかりのツールを使う時は、
AIの記憶に頼ると古い書き方をされてしまい、エラーの原因になります。
・手元にインストールされているファイルを直接確認させる
「公式ドキュメントや、実際にパソコンに入っているライブラリのファイルを直接読んでから書く」というルールを作ったことで、
当て推量ではない正確な修正ができるようになりました。
・「実際に動かして確認する」ところまで任せる
コードを書いただけで完了にせず、実際に起動してボタンを押すテストまでAI自身にやらせることで、
手戻りを減らせることがわかりました。
最初は言語選びの疑問から始まり、後半はバージョン違いのエラー対応でバタバタしましたが、
無事にブログ管理ツールの画面が立ち上がるところまで進めることができました。
まずはこの土台を使って、少しずつ使いやすい形に整えていこうと思います。