lelelemon’s blog

カメの歩みでのんびり学んでいます。

【2025年一人アドベントカレンダー 2日目】理想の開発ルーティンについて考える

はじめに

こんにちは。巷で有名なアドベントカレンダーを、一人で書いてみよう企画になります。
通常アドベントカレンダーはクリスマスまでですが、もうちょっとおかわりして、31日まで駆け抜けます。
今回はのテーマは「理想の開発ルーティンについて考える」です。

理想の開発ルーティンについて考える

理想の開発ルーティン・・自分がゾーンに入れる環境を整えたいですよね。
自分は朝型で、まずはコーヒーをデスクに置きつつ、小さな開発でエンジンをかけプルリクを作る、そして午後には本腰入れる開発をし、途中でランチ。
休憩から戻ったら開発を続け、ある程度完了。疲れてくる頃なので甘いものでリフレッシュ。そのあとで仕上げをしてプルリクを出す。
こんな感じに流れるように開発できたら理想ですね。
流れの中にもある程度空白になるバッファの時間を設け、進捗が遅れていたらそのバッファを割くし、予定通りの進捗なのであれば、
何かしら自分の気になるテーマの検証をやってみるとか。普段の開発タスクと並行して自分の知見を増やすための活動も取り入れ、相乗効果で普段の開発にもフィードバックする。こういうループを回せることが自分にとっての理想です。

終わりに

今回は以上です!
それではまた明日!

【2025年一人アドベントカレンダー 1日目】今年、一番成長を実感した瞬間

はじめに

こんにちは。巷で有名なアドベントカレンダーを、一人で書いてみようというのをやってみようと思います。
通常アドベントカレンダーはクリスマスまでですが、もうちょっとおかわりして、31日まで駆け抜けます。
そして今回が記念すべき第一回の記事になります。
初回のテーマは「今年、一番成長を実感した瞬間」です。

今年、一番成長を実感した瞬間

様々な技術カンファレンスや勉強会に参加するようになったことでしょうか。
これまであまり外に出ていくことをしていませんでしたが、職場の方に声をかけてもらったことをきっかけに、
CfPも出すようになったりと、積極的にチャレンジする姿勢が磨かれたと実感しています。
今年は初めてのLT登壇も経験し、その後もいくつかのイベントでLTをさせてもらって、試行錯誤しながらプレゼンを改善していきました。
まだまだではありますが、人前で話すことに少しずつ慣れてきた感じがあります。
外部のイベントに参加してセッションを聴いたり、懇親会で社外の方々との交流を通じて、様々な技術を知ることができたし、他の方々の苦労されているポイントも聞けて勉強になりました。

終わりに

今回は以上です!
それではまた明日!

【技術イベント参加】 Google Developer Group - DevFest Tokyo 2025

はじめに

こんにちは。Google Developer Group - DevFest Tokyo 2025 に参加したので感想等メモに残したいと思います。


・開催日

2025/11/22

gdg-devfest-tokyo-2025.web.app



・場所
ベルサール渋谷ファースト 2F


・形式

オフライン開催


・参加理由
AndroidやGo, Flutter, 機械学習など、Google が提供する様々な技術について学べる・体験できる場で、とても興味を持ったことが大きいです。
普段業務ではAndroidやGoを触っていることもあり、色々知見を深めたい思いもあり参加しました。

イベントの構成

1日のみのイベントで、同時間帯に50分・60分のセッションが3つおよびワークショップが1つ開催されました。
また、セッション会場外のフロアでは、学生の皆さんが創ったDEMO作品の展示がされていました。(セッションやワークショップ参加に集中しており、DEMO体験できませんでした・・)。
ホットコーヒーのセルフサービスや、お菓子の提供もありました。
最後のセッションではLT大会とクロージングがあり、クロージングのあとはそのまま解散という流れでした。

印象に残ったセッション

ここからは、印象に残ったセッション・ワークショップについて書いていきます。

「[Hands-on] Gemini CLI Harenさん」
  • Gemini CLIでGeminiに何か質問をした際、web検索が必要と判断した場合は、Geminiはgooglesearchというツールを使ってweb検索を行い結果を回答する
  • /tools コマンドでどんなツールが入っているのか確認することができる
  • URLを提示したプロンプトを投げると、webfetchというツールが使われて該当URLの内容を読みにいく
  • !を入力するとシステムコマンドを入力できます(ls, pwd などのコマンドが打てる)
  • もう一度!を入力するとまたプロンプトを打てるようになる
  • nanobanana extensionをGemini CLIに入れると、/generate コマンドでnanobananaを使って画像を作れるようになる
    • コマンド例:
/generate "コーヒーショップ" --variations="lighting,mood" --count=4

gdg-devfest-tokyo-2025.web.app

「[Hands-on] Firebase Studio 田邉 裕貴さん」
  • Firebase Studioについて
    • 生成AIを使ってアプリを構築できるツール
    • AIを組み込んだフルスタックアプリを構築できる
  • Firebase Studioの右側ペインにチャット画面が表示されるので、そこからプロンプトを投げてAIに開発をさせていく
  • プロンプトで、認証でFirebase Authentication, データベースは FireStore を使って機能を実装してくださいという旨の指示を投げると、
  • 自動で Firebase プロジェクトが作成され、指定の機能を使った処理を作成してくれる
  • アプリ作成後は、Firebase Studioの画面右上の Publish ボタンをクリックすることで作ったアプリをデプロイできる
    • Publish ボタンを押してから5分くらい経つとデプロイが完了し、外部からアクセスできるようになる
  • ちなみに、Firebase Studio で使うようなアプリプロトタイプエージェント(生成 AI を使用してフルスタックのエージェント ウェブアプリを開発、テスト、イテレーション、公開する、効率的なノーコード開発フロー)では、
  • 認証やデータベース接続といった機能はアプリ作成初期の時点で組み込むというより、ある程度アプリができてきてから、途中時点から組み込むとうまくいくそうです(公式ドキュメント より)

gdg-devfest-tokyo-2025.web.app

AndroidアプリのAI実装をAndroidifyで学ぶ ー Google公式サンプルによる体験と実装 takahiromさん」
  • Androidifyー自分のAndroid bot が作れる
  • Gogle公式サンプルがある
  • 色々な機能がある
    • 例:
    • カメラに人が映ると撮影ボタンが有効になる
      • ML Kitで判定している
      • Pose Detection APIーオンデバイスでリアルタイムで人を検出するライブラリ
    • Android bot生成用のプロンプトを自動生成する
      • Mlkit prompt API or firebase al logic gemini API
    • 安全でない画像を入れられたときなエラーにする
      • ML kit prompt API or firebase ai logic gemini API
    • テキストからAndroid botを生成
      • Firebase logic ai gemini api
      • Fine tuned modelー画像とテキストのペアを用いて学習
    • 画像からAndroid botを生成
    • 好みの雰囲気の背景を与えた画像生成
      • Firebase logic ai gemini API(画像を作るのをローカルでできないため、このAPIを使っている)
    • 画像の背景を消してステッカーを作る
      • ML kit subject segmentation API
      • 比較的古いデバイスでも動く

gdg-devfest-tokyo-2025.web.app

Android Studio Otter の最新 Gemini 機能 あんざいゆきさん」
  • Studio labsで新しいAI機能を個別に有効化できる
  • Markdownプレビューが出るようになった
  • Gemini Chatが複数の会話スレッドに対応
    • いままでは単一チャットだったため、毎回新しく会話を始める必要があった
  • スクショからコードを作れるようになった
  • すでにあるコンポーズのプレビューで、画像を提示してそれに合うように修正してもらえるようになった
  • エージェント実行のオプションがデフォルトで都度確認になった
    • いままではデフォルトでは一気に作成される感じだった
  • 新しくプロジェクトを作成するときに、create with aiができるようになった、そのときに画像を渡したりもできる

gdg-devfest-tokyo-2025.web.app

学んだこと・得られたこと

Android開発まわりで発見が多かったです。まだGemini3あまり触れていないですが、週末に色々触ってみようと思いました。Firebase Studio, Antigravity, Androidifyこの辺りじっくり触ってみようと思いました。イベント参加しなかったらここまでのモチベーション得られなかったと思うので参加してよかったです。あとイベントの最後にはLT大会が開かれました。それぞれ思い思いの熱いLTを聴くことができ、ここでもモチベーションが上がりました。

今後のアクション

  • Firebase Studio, Antigravity, Androidifyを触る

終わりに

初めてのGDG Tokyo参加でした。DEMOブースでは未来を感じるような面白い展示があったそうでしたが見逃してしまったのが心残りです。次回は時間に余裕を持ってイベント全体を楽しめるように参加したいと思います。
運営関係者の方々、スピーカーや協賛の方々、イベント開催ありがとうございました!

【技術イベント参加】 FlutterKaigi 2025

はじめに

こんにちは。FlutterKaigi 2025 に参加したので感想等メモに残したいと思います。


・開催日

2025/11/13

2025.flutterkaigi.jp



・場所
大手町プレイスホール&カンファレンス 1F・2F


・形式

オフライン開催


・参加理由
いまは業務でFlutterを書くことはなくなりましたが、個人開発でFlutterを書いており、もともとFlutterに興味を持っていました。そんな中、Flutterに関するカンファレンスがあることを知り、より知見を深めたいと思い参加をしました。

イベントの構成

1日のみのイベントで、同時間帯に30分のセッションが2つ・3つ開催されました。
また、セッション会場外のフロアでは、スポンサーブースが出店されていてそこで各社のサービスを知れたり、エンジニアの方と話したり、スタンプラリーもありました(スタンプラリーは全コンプリートしました!)。
ホットコーヒーのサービスや、お昼にはお弁当・お茶の提供もありました。
最後のセッションが終了して、会場準備等で30分ほどの待ち時間の後、懇親会がありました。

印象に残ったセッション

ここからは、印象に残ったセッションについて書いていきます。

「Flutterコントリビューションのススメ koji-1009さん」
  • Flutter SDKの開発側と利用側の認識の差、目指すゴールの違いがあるのではないか
    • 開発側は機能開発を通じてSDKをより魅力的なものにしたい
    • 利用側は不具合を対応して安心して使えるSDKにしてほしい
  • 我々が見聞きするのは外向きに発表されたものだけで、内情は推測するしかない
  • Issue上などで正しさを議論するより、PRつくって正しいコードを提示する方が簡単
  • openな領域への積極的な参加を推奨
  • 積極的、直接的に関わることで、自分を取り巻くリスクをコントロールできる
  • コントロールできないリスク
    • Flutter開発が中断されるリスク
    • アメンバーが異動・離脱するリスク
    • リリースタイミングを事前に把握できない
  • FlutterのコードはGitHubで公開されており、75%はdartで書かれている->Flutter書ける人は75%は理解できる
  • コントリビューションはコストが高い
  • 楽しんでやるのが大事
  • 問題を徹底的に理解したうえで解決案を提案することが必要
  • AI使っても良いが、そのPRで何で直るのかを説明できる必要がある
  • テストコードが役立つ
  • 自分が関わることでFlutterの開発は1つ前進する
「Flutterアプリで収益を上げる方法 Perttu Lähteenlahtiさん」
  • Flutterアプリで収益を上げるのが難しい理由
    • ユーザーに「お金を払う理由」を納得してもらう必要があり、そもそもの心理的ハードルが高い
    • 課金まわりはバックエンド実装・検証・各ストアの仕様対応など開発コストが重い
    • iOS / Android など複数ストア対応が必要で、規制変更や審査要件のアップデートにも常に追従が必要
    • サブスクアプリ全般が直面するように、継続価値の提供が不可欠で、ユーザー離脱リスクが高い
  • Flutterで選べるマネタイズ手法
    • 広告収入(Ads)
      • 実装が最も簡単でリスクが低い
      • 1ユーザー当たりのバリューは低いため、大規模ユーザーベースが必要
    • コンシューマブル課金(Consumables)
      • コイン / クレジット / ジェムなどの“使い切り型”
      • 繰り返し購入してくれるかはユーザー行動に依存
    • サブスクリプション(Recurring)
      • 多くのアプリが採用するモデル
      • ただし「継続価値の提供」が課題で、いずれ離脱が起こる
    • バーチャル通貨(Virtual Currency)
      • Duolingo Gems や、AI動画生成アプリの「1秒あたり課金」など
      • ユーザーが価値を感じやすく、応用範囲が広い
      • ※現実的には → 複数モデルの組み合わせ(広告+サブスクなど)が一般的
  • RevenueCat を使う理由
    • 課金周りをすべて自前で作るのは非常に大変
    • Flutter対応はもちろん、iOS / Android / Web / 各言語に幅広く対応
    • ストアごとの仕様違い、ペイウォール管理、アナリティクスなど面倒な領域を肩代わり
    • 売上が 2,500ドルに達するまでは無料で利用可能
  • RevenueCat SDK でできること・基本概念
    • 初期化(initializing)
      • アプリ起動時に SDK を初期化
      • カスタマー識別(ID / 一時ID)にも対応し、ログイン連携にも柔軟
    • ペイウォール(paywalls)
      • Products → Paywalls → Entitlements の流れで構成
      • Webブラウザ上でペイウォールUIを構築可能
      • A/B テストもできる
      • ペイウォール変更にアプリ再リリース不要
      • カスタムUIも作成可能で、複数商品を一覧表示できる
    • エンタイトルメント(entitlement)
      • 「ユーザーが買ったことで得られる権利」
      • 例:月額プラン / 年額プラン / ライフタイム
      • どの entitlements が有効かで、表示するプランや UI を出し分け可能
  • アプリ開発者として重要な姿勢
    • 支払まわりに工数をかけすぎないこと
    • → その領域は RevenueCat に任せ、
    • 時間は「ユーザーが求める機能開発」に集中すべき
    • 値上げの戦略
      • 自分が「これくらいかな?」と思った金額の2倍を設定してもよい
      • 多くの開発者は価格を慎重にしすぎる傾向
      • 値下げはいつでもできるが、ユーザーが増えてから値上げするのは難しい
    • サブスク期間・価格帯など、さまざまなパターンを試すこと
    • ユーザーのエンゲージメントを高める体験づくりが、結局もっとも重要
「モバイル端末で動くLLMはどこまで実用的なのか KyoheiG3さん」
  • なぜいまオンデバイスLLMか
    • 応答速度、通信不要
    • どこでも使える
    • ユーザーデータがデバイス外に出ない
    • 一方で、
    • バッテリー消耗が早い
    • モデルをアプリに埋め込むので、アプリサイズが大きくなる
  • FlutterでオンデバイスLLMを動すためのライブラリが提供されている
  • どのモデルを選ぶかで使えるライブラリが変わってくる
  • Cactusフォーマット
    • オンデバイスでの利用に特化
    • ARM CPUに最適化されている
    • React-NativeやKMPからも利用可能
  • モデルは学習した時点の知識しかない
  • そのため、ツール呼び出しなどをできるようにする
  • = Function Calling
  • RAGは、ベクトル検索と推論の両方の負荷に注意する

学んだこと・得られたこと

Flutter SDK開発の現在地が知れました。Flutterの開発は進んでいるものの、圧倒的に開発の人数が足りないので、自分でIssue対応してコミュニティに貢献する気概が大事だと感じました。
他のOSSにコントリビュートした経験はありますが、Flutterはまだなので対応しやすいIssueについてPRを送ってみたいと思います。
といいつつ、Flutterの深い理解が必要なので、それも合わせて。
オンデバイスLLMについては用語だけでなあなあにしてしまっていたので、基本的な知識から、認識をブラッシュアップできてよかったです。
今日一日でFluitterに関する用語を多々認識できたので、小さく検証を進めていこうと思います。

今後のアクション

  • Flutterにコントリビュートできるようになるために、既存のIssueや近しい議論を探す
  • オンデバイスLLMの実装を試す

終わりに

初めてFlutterKaigiに参加しました。Flutterが思っていたよりもずっと盛り上がっていて、周りからも熱気を感じました。
Flutterオワコンと言われて久しいですが、まだまだ現役ですし、コントリビューションもやってみようと思いました。
アプリ収益化についても全く知らない世界の話で、視野が広がりました。
面白いイベントを企画運営してくださったスタッフの方々にお礼です。ありがとうございました!

複数AIを協調させてアプリを作るオーケストレーション開発に挑戦

はじめに

こんにちは。皆さん、普段の開発でAIは使っていますか?私はClaude Codeをメインに、Gemini, GitHub Copilot, Devin, Codex, Warp Codeなどなど使っています。AIを使いながら開発を進めているのですが、ここでふと、AI同士で開発を行わせてみることでより開発を効率化できるのでは?と思い立ち、複数のAIを協調させた開発を検証してみることにしました。

今回試したコードは以下にありますので、ご自由にお使いください。

github.com

概要

この検証では、単一のAIを使うのではなく、複数のAIにそれぞれ役割を持たせ、役割の異なるAI同士が協調して動くようにしました。
以下のような構成にしました。

役割 AI 内容
オーケストレーター Claude Code 他のAIへ指示を出し、進行管理を担当
要件分析、調査 Gemini ユーザー要求をまとめ、システム要件や仕様まとめを担当
設計 Claude Code システム設計を担当
実装 GitHub Copilot 実際のコード生成を担当
ビルド、テスト Warp Code 出来上がったアプリのビルド・テストを担当
レポート Claude Code ユーザーに対して、完成したアプリのレポーティングを担当

システム構成

オーケストレーター(Claude Code)が司令塔となり、SDK呼び出しやCLIコマンド実行を通じて他のAIエージェントを順番に実行します。
各エージェントの出力結果を、次のエージェントが入力として利用することで、シンプルなパイプライン連携をしています。

以下のような流れで、各AIが処理を進めます。

1. Claude Code が起点となり、Gemini に仕様調査を依頼
2. Gemini が要求分析、要件定義を行う
3. Claude Code がその結果を受け取りシステム設計を行う
4. Copilot が設計内容を受け取り、アプリを実装
5. Warp Code がそのアプリビルド、実行し、テストと改善提案を実施
6. 最後に Claude Code が全体の成果をまとめ、レポーティング

動作確認

それでは試しに実行してみたいと思います。

依頼文:「Flutterで簡易なタスク管理アプリを作ってください、タスクの登録・完了・削除ができ、進捗を一覧で見られるようなシンプルな構成で構いません。」

python orchestrator.py
🚀 Multi-AI Cooperationシステムを開始します!
   'quit'または'exit'で終了します
   新しいフェーズベースアーキテクチャを使用

⚙️  システム設定
==============================
📄 詳細表示モード (各フェーズの内容を詳しく表示) [y/N]: y

🔍 詳細表示モードが有効です:
   - 各フェーズの実行内容を詳細に表示
   - AI の応答内容を抜粋表示
   - ファイル作成・検証結果の詳細
   ※ より多くの情報が表示されます

💬 実行したいタスクを入力してください: Flutterで簡易なタスク管理アプリを作ってください、タスクの登録・完了・削除ができ、進捗を一覧で見られるようなシンプルな構成で構いません。

🎯 タスク開始: Flutterで簡易なタスク管理アプリを作ってください、タスクの登録・完了・削除ができ、進捗を一覧で見られるようなシンプルな構成で構いません。
🤖 AI協調フロー: Gemini → Claude → Copilot → WarpCode → Claude
🔍 詳細表示モードで実行中...
======================================================================
🚀 Multi-AI協調ワークフローを開始します
📝 リクエスト: Flutterで簡易なタスク管理アプリを作ってください、タスクの登録・完了・削除ができ、進捗を一覧で見られるようなシンプルな構成で構いません。
============================================================


実行中の様子

🔄 Phase 1/5: REQUIREMENT - 実行中...
   📋 Geminiが要件分析・情報収集を実行中...
   ・・・・・・・・・・・・・・・・・・・・
🔄 [requirement] 要件分析開始...
✅ [requirement] フェーズ完了: dict
✅ Phase 1 完了: requirement (17秒)

📄 REQUIREMENTフェーズ詳細結果:
   🔍 Gemini分析結果 (抜粋):
   ## Flutter 簡易タスク管理アプリ開発 ユーザーリクエスト詳細分析
   ### 【ユーザーリクエスト】
   Flutterで簡易なタスク管理アプリを作ってください、タスクの登録・完了・削除ができ、進捗を一覧で見られるようなシンプルな構成で構いません。
   ### 【分析項目】
   #### 1. 機能要件
   ... (続きあり、総157行)
   📋 要件分析完了
──────────────────────────────────────────────────────────────────────

🔄 Phase 2/5: DESIGN - 実行中...
   📐 Claude Codeが技術設計・仕様変換を実行中...
   ・・・・・・・・・・・・・・・・・・・・
🔄 [design] 設計フェーズ開始...
✅ [design] フェーズ完了: dict
✅ Phase 2 完了: design (0秒)

📄 DESIGNフェーズ詳細結果:
   📐 技術設計仕様 (抜粋):
   # 技術設計仕様書
   ## 1. プロジェクト概要
   **ユーザーリクエスト**: Flutterで簡易なタスク管理アプリを作ってください、タスクの登録・完了・削除ができ、進捗を一覧で見られるようなシンプルな構成で
   ## 2. 要件分析結果の整理
   ## Flutter 簡易タスク管理アプリ開発 ユーザーリクエスト詳細分析
   ### 【ユーザーリクエスト】
   ### 【分析項目】
   #### 1. 機能要件
   ... (詳細仕様あり、総240行)
   📐 技術設計完了
──────────────────────────────────────────────────────────────────────

🔄 Phase 3/5: IMPLEMENTATION - 実行中...
   💻 Copilotが実装・コード生成を実行中...
   ・・・・・・・・・・・・・・・・・・・・
🔄 [implementation] 実装フェーズ開始...
🔄 [implementation] プロジェクトフォルダ作成: generated_projects/20251111_182807_Flutterで簡易なタスク管理アプリを作ってくださいタス
✅ [implementation] フェーズ完了: dict
✅ Phase 3 完了: implementation (7分54秒)

📄 IMPLEMENTATIONフェーズ詳細結果:
   💻 プロジェクト作成完了:
   📁 保存場所: generated_projects/20251111_182807_Flutterで簡易なタスク管理アプリを作ってくださいタス
   📄 作成ファイル (1個):
      - my_task_app (544 bytes)
   🤖 Copilot応答 (抜粋):
      I'll implement a Flutter task management app based on the technical sp...
      ✓ Check current directory structure
         $ pwd && ls -la
         ↪ 5 lines...
   💻 実装完了: 1 ファイル作成
   📁 保存先: generated_projects/20251111_182807_Flutterで簡易なタスク管理アプリを作ってくださいタス
──────────────────────────────────────────────────────────────────────

🔄 Phase 4/5: VERIFICATION - 実行中...
   🧪 WarpCodeが自動検証・実行テストを実行中...
   ・・・・・・・・・・・・・・・・・・・・
🔄 [verification] 自動検証フェーズ開始...
⚠️ Warp agent timed out (took longer than 90s).
✅ [verification] フェーズ完了: dict
🔄 [verification] 一部の検証項目で問題が検出されました
✅ Phase 4 完了: verification (1分30秒)

📄 VERIFICATIONフェーズ詳細結果:
   🧪 検証結果: ⚠️ 一部問題あり
   🔬 実行テスト詳細:
      1. ❌ Project Structure Check: プロジェクト構造に問題あり
      2. ❌ WarpCode Execution Test: WarpCode実行失敗
      3. ❌ Basic Tests: 基本テストで問題検出
   🧪 検証完了: 3 テスト実行 - 一部テスト失敗
──────────────────────────────────────────────────────────────────────

🔄 Phase 5/5: REPORT - 実行中...
   📊 Claude Codeがレポート・改善提案を生成中...
   ・・・・・・・・・・・・・・・・・・・・
🔄 [report] レポート生成フェーズ開始...
🔄 [report] プロジェクトレポート保存: generated_projects/20251111_182807_Flutterで簡易なタスク管理アプリを作ってくださいタス/PROJECT_REPORT.md
✅ [report] フェーズ完了: dict
✅ Phase 5 完了: report (15秒)

📄 REPORTフェーズ詳細結果:
   📊 生成されたレポート:
   📋 プロジェクト概要:
      ## プロジェクト基本情報
      - **リクエスト**: Flutterで簡易なタスク管理アプリを作ってください、タスクの登録・完了・削除ができ、進捗を一覧で見られるようなシンプルな
      - **作成日時**: 2025-11-11 18:27:50
      - **プロジェクトパス**: generated_projects/20251111_182807_Flutterで簡易なタスク管理アプリを作ってく
      ## フェーズ実行結果
   📈 実行分析結果:
      ## 実行分析
      - **全体成功率**: 75.0% (3/4)
      - **検証結果**: 要改善
        - ❌ Project Structure Check: プロジェクト構造に問題あり
   🔮 Geminiベンチマーク分析 (抜粋):
      ## Flutterタスク管理アプリ プロジェクト分析 (外部ベンチマークとの比較)
      この分析では、提示されたFlutterタスク管理アプリのプロジェクト概要に基づいて、類似プロジェクトとの比較、技術的品質評価、改善提案、学習・参考資料
   📊 プロジェクトレポート生成完了
──────────────────────────────────────────────────────────────────────

============================================================
🎉 Multi-AI協調ワークフロー完了
📈 実行統計:
   - 実行フェーズ数: 5
   - 作成ファイル数: 0
   - エラー数: 0
   - 総実行時間: 9分56秒

⏱️  フェーズ別実行時間:
   - 要件・調査: 17秒
   - 設計・仕様: 0秒
   - 実装: 7分54秒
   - 検証・実行: 1分30秒
   - レポート: 15秒
   - システムオーバーヘッド: 0秒

📁 プロジェクトフォルダ: generated_projects/20251111_182807_Flutterで簡易なタスク管理アプリを作ってくださいタス

🎯 総合成功率: 80.0%
======================================================================
🎉 タスク完了!
⏱️  総実行時間: 9分56秒

📊 フェーズ別実行時間:
   - 要件・調査: 17秒
   - 設計・仕様: 0秒
   - 実装: 7分54秒
   - 検証・実行: 1分30秒
   - レポート: 15秒

📁 プロジェクト保存先: generated_projects/20251111_182807_Flutterで簡易なタスク管理アプリを作ってくださいタス

======================================================================


出力されたファイル

  ├── PROJECT_REPORT.md
  └── my_task_app
      ├── IMPLEMENTATION.md
      ├── README.md
      ├── analysis_options.yaml
      ├── android
      │   ├── app
      │   │   ├── build.gradle.kts
      │   │   └── src
      │   │       ├── debug
      │   │       │   └── AndroidManifest.xml
      │   │       ├── main
      │   │       │   ├── AndroidManifest.xml
      │   │       │   ├── java
      │   │       │   │   └── io
      │   │       │   │       └── flutter
      │   │       │   │           └── plugins
      │   │       │   │               └── GeneratedPluginRegistrant.java
      │   │       │   ├── kotlin
      │   │       │   │   └── com
      │   │       │   │       └── example
      │   │       │   │           └── my_task_app
      │   │       │   │               └── MainActivity.kt
      │   │       │   └── res
      │   │       │       ├── drawable
      │   │       │       │   └── launch_background.xml
      │   │       │       ├── drawable-v21
      │   │       │       │   └── launch_background.xml
      │   │       │       ├── mipmap-hdpi
      │   │       │       │   └── ic_launcher.png
      │   │       │       ├── mipmap-mdpi
      │   │       │       │   └── ic_launcher.png
      │   │       │       ├── mipmap-xhdpi
      │   │       │       │   └── ic_launcher.png
      │   │       │       ├── mipmap-xxhdpi
      │   │       │       │   └── ic_launcher.png
      │   │       │       ├── mipmap-xxxhdpi
      │   │       │       │   └── ic_launcher.png
      │   │       │       ├── values
      │   │       │       │   └── styles.xml
      │   │       │       └── values-night
      │   │       │           └── styles.xml
      │   │       └── profile
      │   │           └── AndroidManifest.xml
      │   ├── build.gradle.kts
      │   ├── gradle
      │   │   └── wrapper
      │   │       ├── gradle-wrapper.jar
      │   │       └── gradle-wrapper.properties
      │   ├── gradle.properties
      │   ├── gradlew
      │   ├── gradlew.bat
      │   ├── local.properties
      │   ├── my_task_app_android.iml
      │   └── settings.gradle.kts
      ├── ios
      │   ├── Flutter
      │   │   ├── AppFrameworkInfo.plist
      │   │   ├── Debug.xcconfig
      │   │   ├── Generated.xcconfig
      │   │   ├── Release.xcconfig
      │   │   ├── ephemeral
      │   │   │   ├── flutter_lldb_helper.py
      │   │   │   └── flutter_lldbinit
      │   │   └── flutter_export_environment.sh
      │   ├── Podfile
      │   ├── Runner
      │   │   ├── AppDelegate.swift
      │   │   ├── Assets.xcassets
      │   │   │   ├── AppIcon.appiconset
      │   │   │   │   ├── Contents.json
      │   │   │   │   ├── Icon-App-1024x1024@1x.png
      │   │   │   │   ├── Icon-App-20x20@1x.png
      │   │   │   │   ├── Icon-App-20x20@2x.png
      │   │   │   │   ├── Icon-App-20x20@3x.png
      │   │   │   │   ├── Icon-App-29x29@1x.png
      │   │   │   │   ├── Icon-App-29x29@2x.png
      │   │   │   │   ├── Icon-App-29x29@3x.png
      │   │   │   │   ├── Icon-App-40x40@1x.png
      │   │   │   │   ├── Icon-App-40x40@2x.png
      │   │   │   │   ├── Icon-App-40x40@3x.png
      │   │   │   │   ├── Icon-App-60x60@2x.png
      │   │   │   │   ├── Icon-App-60x60@3x.png
      │   │   │   │   ├── Icon-App-76x76@1x.png
      │   │   │   │   ├── Icon-App-76x76@2x.png
      │   │   │   │   └── Icon-App-83.5x83.5@2x.png
      │   │   │   └── LaunchImage.imageset
      │   │   │       ├── Contents.json
      │   │   │       ├── LaunchImage.png
      │   │   │       ├── LaunchImage@2x.png
      │   │   │       ├── LaunchImage@3x.png
      │   │   │       └── README.md
      │   │   ├── Base.lproj
      │   │   │   ├── LaunchScreen.storyboard
      │   │   │   └── Main.storyboard
      │   │   ├── GeneratedPluginRegistrant.h
      │   │   ├── GeneratedPluginRegistrant.m
      │   │   ├── Info.plist
      │   │   └── Runner-Bridging-Header.h
      │   ├── Runner.xcodeproj
      │   │   ├── project.pbxproj
      │   │   ├── project.xcworkspace
      │   │   │   ├── contents.xcworkspacedata
      │   │   │   └── xcshareddata
      │   │   │       ├── IDEWorkspaceChecks.plist
      │   │   │       └── WorkspaceSettings.xcsettings
      │   │   └── xcshareddata
      │   │       └── xcschemes
      │   │           └── Runner.xcscheme
      │   ├── Runner.xcworkspace
      │   │   ├── contents.xcworkspacedata
      │   │   └── xcshareddata
      │   │       ├── IDEWorkspaceChecks.plist
      │   │       └── WorkspaceSettings.xcsettings
      │   └── RunnerTests
      │       └── RunnerTests.swift
      ├── lib
      │   ├── main.dart
      │   ├── models
      │   │   └── task.dart
      │   ├── screens
      │   │   ├── add_task_screen.dart
      │   │   └── home_screen.dart
      │   ├── services
      │   │   └── task_service.dart
      │   └── widgets
      │       ├── task_item.dart
      │       └── task_list.dart
      ├── my_task_app.iml
      ├── pubspec.lock
      ├── pubspec.yaml
      └── test
          └── widget_test.dart

作成されたアプリのデモ

シンプルなタスク管理アプリが作成されました。

学び・気づき

単純なアプリの例でしたが、要件定義〜検証までの一連のプロセスを複数AIを組み合わせて動かせることを知りました。
もちろん単一のAIでも同様のことは可能と思いますが、複数のAIの視点を組み合わせることと合わせて、
AIに指示するプロンプトや、CLAUDE.mdなどコンテキストファイルのカスタマイズもすることで、よりアウトプットの質の向上を見込めると感じました。
今回のように広い工程をAIにやらせるのではなく、たとえば設計工程だけに絞って、あるAIのアウトプットを別のAIが批判的観点でレビューして、それをさらにまた別のAIがレビューして・・を繰り返した結果を参考にすることで、人間1人では詰めきれない、思考の幅を広げることにも寄与できるかもと思いました。

今後の展望

次のステップとしては以下を考えています。

  • 検証フェーズのテスト実行がうまくいっていない箇所があるので調査
  • OpenAIなど他のAIの組み合わせも検証し、AIごとの得意領域を検証し、ワークフローに組み込んでみる
  • 設計工程など、単一の工程に限定したワークフローを組んでみる
  • 実プロジェクトでの部分適用(リサーチ+テスト自動化など)

終わりに

AIを“複数人チーム”のように動かしてみると、単体では見えなかった協働の難しさと面白さが見えてきました。
全工程をまるまる担当させるのはまだまだ厳しいと思いますが、一部工程で活用してみるなどはアリかなと感じました。
今後も少しずつ改良しながら、より実践的なAIオーケストレーションの形を探っていきたいと思います。
今回の内容が何かご参考になれば幸いです。

【技術イベント参加】 Kotlin Fest 2025

はじめに

こんにちは。Kotlin Fest 2025 に参加したので感想等メモに残したいと思います。


・開催日

2025/11/1 ~ 2025/11/1

2025.kotlinfest.dev


・場所
東京コンファレンスセンター品川 4F・5F


・形式

オフライン開催


・参加理由
業務でKotlinを書くことがあるのと、どちらかというとコードレビューでKotlinを触ることが多いです。そんな中で最新のKotlinの記法やアーキテクチャにキャッチアップがあまりできていなく、コードレビューの質を高めるためにも、Kotlinに関する知見が集まるKotlin Festで何かヒントを得られればと思い参加しました。

イベントの構成

1日のみのイベントで、同時間帯に20分もしくは40分のセッションが2つ・3つ開催されます。
また、セッション会場外のフロアでは、スポンサーブースが出店されていてそこで各社のサービスを知れたり、エンジニアの方と話したり、スタンプラリーもありました。
セルフサービスでホットコーヒーやお菓子が食べれたりと、ちょっとした嬉しい休憩スポットもあって快適に過ごせました。
最後のセッションが終了してクロージングの後、アフターパーティーが開かれました。
アフターパーティーでは、他の参加者との交流や、ビュッフェ形式の食べ物や、ドリンクの提供がありました。

印象に残ったセッション

「ネストしたdata classの面倒な更新にさようなら!Lensを作って理解するArrowのOpticsの世界 shiita0903さん」
  • 複数のdata classが入れ子になった構造で末端のオブジェクトの値を書き換えたインスタンスを取得したい、というような場合、
  • .copy()の連鎖が続き、冗長で可読性の悪い辛みがある
  • そこで、Arrow Opticsというライブラリで簡潔に書けるやり方を紹介していただいた
  • 例として、Arrows OpticsのLensを使うと、.modify()に対して、実際に変更したいインスタンスと変更のラムダ関数を渡すような、以下のような書き方
val updated = (User.profile.address.city).modify(user) { it.lowercase() }
  • KSPプラグインを使うことで@optics アノテーションを付けた data class からコードを自動生成できる
  • この自動生成したコードを使うことで、copy(copy(copy(...))) と書かずに済むようになる
  • Lensはイミュータブルなdata classを安全に更新できる便利な仕組みだが、以下のようなケースには対応していない
    • Map や List のような コレクションの中身 を直接操作したいとき
    • sealed class のような 型の分岐構造 を安全に扱いたいとき
  • そこでArrows Opticsの他の仕組みである、Traversal / Optional / Prism / Iso などをLensと組み合わせることで柔軟に対応可能
  • たとえば、以下のように Lens + Traversal でコレクションの中身の値を置き換えることができる (.every()は、Traversal.everyという関数を使っている)
val updated = Team.members
    .every(Profile.address.some.city)
    .modify(team) { it.uppercase() }
  • 一度セッション聴いただけでは理解が追いつかなかったので、時間取って触ってみようと思います。

2025.kotlinfest.dev

「「動く」サンプルでスムーズなコミュニケーションを 〜CMP時代のKotlinPlayground活用最前線〜 chigichan24さん」
  • Kotlin Playground を日常的に業務でも効果的に使えるんじゃないとヒントを得たセッションだった
  • バージョンを切り替えてバージョンごとのKotlinの挙動を確かめられる -> 簡単に最新機能に触れられる
  • 但し、本腰を入れた調査はwebブラウザ上では難しい
  • when句など一部バージョンでは想定通りに動かない場合がある
  • JVM, JS, Compose Multiplatform, wasm, JUnit, canvas などのプラットフォームを指定して実行できる
  • JUnitモードは、テストを実行できる。但し、mockk, mockitokotlinなど有名どころのモックライブラリは使えないので、微妙かも
  • 短縮リンクをコピーして、リンク共有したり、
  • share codeでコード共有、htmlコードを出力できる
  • コードレビューでも活用できそう
    • -> コメントと合わせて、こんな感じになります、のようなリンクも添えることでレビューの質が高まる
  • 業務のコードはそのまま載せずに、書き換えたもので動作確認するのが無難

2025.kotlinfest.dev

「KoogではじめるAIエージェント開発 hiro(Nosho Hiroaki)さん」
  • AI関連は圧倒的にPythonが多い中、全てKotlinでAIエージェント開発ができるKoogを紹介いただいた
  • 自律的に動き複雑なタスクを実行する、まさにAIエージェントを開発できる
  • 開発においては、Kotlinの静的型付けのメリットを生かせる
  • AIコードとアプリコードをすべてkotlinで作れる(AI, backend, UI全部Kotlin)
  • 幅広いLLMモデルに対応している
  • 処理に失敗しても自動ロールバックする機能があり、安心して使える
  • KMPに対応、サーバーサイドは、KtorやSpring bootに対応
  • Koogには豊富な機能があり、他のAIエージェント開発フレームワークと同等以上の機能を持っている
  • ただ、現時点ではKoogの開発支援ツールはない -> そのうち対応されると思われる
  • 公式リソースが充実しているので、キャッチアップにはそれを使うのがおすすめ
  • ワークフローやツールを組み合わせながら、AIエージェントを作っていく
  • 事前定義された、組み込みのツールが充実しているので、自分で新たに定義しなくても、それらを組み合わせることで目的のAIエージェントが開発できる
  • こちらもセッション一度聴いただけではなかなか理解できなかったので、時間取って触ってみようと思います。

2025.kotlinfest.dev

学んだこと・得られたこと

KotlinでAIエージェント開発ができることが知れて驚きました。業務の合間で小さなAIエージェント作ってみたり、AI機能触ってみたりしていますが、大体がPythonなので、Kotlinでも書けることを知れて視野が広がりました。
他にも、Javaと比較したKotlinとの記法の違いだったり、KotlinでWeb開発してみた事例だったり、Kotlinでできることの広がりを感じられたことも大きかったです。
最近Kotlinのキャッチアップがかなり遅れ気味なのを実感しているところだったので、良い刺激になったし、アフターパーティーでもKotlin使ってる方と色々話せたことも良かったです。KMPの勢いを感じたので、そろそろ触ってみようと思います。

今後のアクション

  • KoogでAIエージェント開発を実践してみる
  • KMPで何かアプリを作る(普段Flutterで個人開発しているので、Flutterとの開発体験の違いを実感として得る)

終わりに

初めてのKotlin Fest参加でした。オフラインのみの開催で、当日は415名もの方が参加されたそうです。会場も綺麗で、セッションルームは全てテーブルと椅子が用意されていたので、快適にセッションを聴講できました。
また次回あればぜひ参加したいです。イベントスタッフの方々、スポンサー各社、登壇者の方々、楽しいイベントをありがとうございました!

【Flutter】TextFieldのパスワード入力で表示・非表示を切り替えられるようにする

はじめに

こんにちは。Flutter を書いていて TextField でパスワード入力を実装していた際に、よくあるパスワードをマスクするやり方を調べて試したので、そのメモになります。

実装例

TextFieldの、obscureText property を使うことで文字列の表示・非表示を切り替えることができます。以下はサンプルコードです。

import 'package:flutter/material.dart';

class PasswordTextFieldSample extends StatefulWidget {
  const PasswordTextFieldSample({super.key});

  @override
  State<PasswordTextFieldSample> createState() => _PasswordTextFieldSampleState();
}

class _PasswordTextFieldSampleState extends State<PasswordTextFieldSample> {
  bool _obscureText = true; // 初期状態はパスワードを隠す

  void _toggleVisibility() {
    setState(() {
      _obscureText = !_obscureText;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Password TextField Sample')),
      body: Padding(
        padding: const EdgeInsets.all(16.0),
        child: TextField(
          obscureText: _obscureText,
          decoration: InputDecoration(
            labelText: 'Password',
            suffixIcon: IconButton(
              icon: Icon(
                _obscureText ? Icons.visibility_off : Icons.visibility,
              ),
              onPressed: _toggleVisibility,
            ),
            border: const OutlineInputBorder(),
          ),
        ),
      ),
    );
  }
}

ポイント

obscureText プロパティが true のとき、入力中の文字が「●」で隠される

IconButtonを使って _obscureText の状態を切り替えることで、ユーザーがパスワードの表示/非表示を自由に操作できる

見た目を整えるには、InputDecoration の suffixIcon が便利

終わりに

Flutter では、TextFieldウィジェットに用意されているobscureTextプロパティを活用することで、パスワード入力欄をとてもシンプルに実装できます。
ログインフォームなどで頻出するUIなので、ぜひご自身のプロジェクトでも試してみてください!