この記事では、2026年7月に取り組んだ個人開発と仕事について振り返ります。
7月は、単に何を作ったかだけでなく、考え方や判断、迷いも多く残った月でした。まだ答えが出ていないことも含め、今の自分が考えていることを記録しておきます。
Lukurauhaを作り始めた
7月から、個人開発でLukurauhaというWebアプリを作り始めました。
Lukurauhaは、ドキュメントや長い文章を、本を読むような感覚で読みやすくするためのアプリです。単に文章を表示するのではなく、落ち着いて長文を読み進められる体験を作りたいと思っています。
技術スタックにはAstroを選びました。作り始めた時点では、認証やログイン、データベースを強く必要としていませんでした。クライアント側で大規模な処理をする想定もなかったため、まずは軽く始めたいと考えました。
Next.jsをはじめとしたフルスタックの選択肢もあります。Astroも、必要に応じてサーバー側の機能を取り入れられます。それでも、最初からすべてを備えるのではなく、必要になったものを後から足していく考え方が、今回の開発には合っていると感じました。
また、Astroはコンテンツを中心とした設計と相性がよいフレームワークです。「本」もコンテンツの一種として扱えるため、その特徴を生かせるのではないかと考えています。
一方、実際に開発を進めると、当初の想定よりクライアント側のスクリプトが増えてきました。現在は、TypeScriptで一から実装している処理も多くあります。
Astroには、SSGとSSRの使い分けや、Content Layer API、Content Collectionsによるコンテンツ管理などの機能があります。スキーマに合わないデータや記述上の問題をビルド時に検出し、静的生成とCDNを生かして高速に配信することもできます。
現状は、こうした利点を十分に使えていません。これからアーキテクチャを見直し、Astroを活かせる構成へ少しずつ整えるほか、場合によっては、AstroのIsland機能でSvelteやPreactを使った方がコードを整理しやすい可能性もあります。他のフレームワークにリプレイスすることも選択肢にはあります。ただし、フレームワークのバンドルやランタイム自体を持つことで動作が重くなる可能性もあるため、そのあたりはトレードオフだと考えています。同時にリファクタリングも進め、機能を増やしながらコードの質を保てる状態を作っていきます。
読書を続けるためのAIアシストを考えた
LukurauhaにAIを使った読書アシスト機能の導入を考えています。単にAI機能を追加したいからではありません。もともと、自分が長い文章をきちんと理解しながら読めるようになりたい、という目的があったためです。
本や長文を読んでいると、知らない言葉や概念に出会い、途中で意味を理解できなくなることがあります。後のページまで進んでから、前に書かれていた内容の意味に気づくこともあります。分からないまま読み進めた結果、文章の内容がほとんど頭に入ってこないこともありました。
分からない箇所を自分で振り返り、調べ直すことで記憶に残る面もあります。しかし、ページを戻ったり、読書画面を離れて検索したりすることは、自分にとって大きな手間でした。それが、本を最後まで読めなくなった理由の一つでもあります。
SNSや短いコンテンツに触れる時間が増える中で、長文を理解するための語彙力や読解力は、自分の弱点になっていると以前より強く感じます。分からない内容をAIに質問し、理解できるまで説明してもらうことはできます。ただ、そのたびに別の画面へ移ると、読書の流れが途切れてしまいます。
AIを答えそのものとして使うのではなく、自分で読み続けるための補助輪として使いたい。 読んでいる画面の中で難しい箇所の補足を確認でき、文章から離脱せずに読み続けられる体験を作りたいと思っています。
実現するには、対象とする読者、文章のどの範囲を補足するか、説明をどこまで詳しくするかを考える必要があります。使うAIモデルや課金方法も検討しなければなりません。補足が多すぎれば、かえって読書を邪魔する可能性もあります。
AIの回答を表示するだけでは、使える読書アシストにはならないはずです。表示方法や挙動も含めて仮説を立て、実装し、実際に使いながら改善していきます。この過程を通じて、仮説を立てて検証する力も鍛えたいです。
仕事で感じたこと
7月後半から、仕事では自社サイトのトップページやLPの制作に取り組みました。制作ではFigma MCPも一通り利用しました。それでも、ツールの使い方とは別に、進め方やコミュニケーションには改善できる部分がありました。
もっと適切なタイミングで質問し、聞きたいことを明確に伝えられていれば、やり取りの往復を減らせたかもしれません。また、現状は上司のレビューを受けなければ公開できない部分があり、自分の確認力や実力の不足も感じています。
これからは自分に適度な厳しさを持ち、セルフレビューの目を養いたいです。記憶や注意力だけに頼らず、チェックリストを作るなど、確認を仕組みにすることも考えています。
一方で、依頼されたものをそのまま作るだけでなく、自分の意見やアイデアを相談して形にすることは、以前より意識できました。アニメーションを提案したり、曖昧な依頼に対して自分なりの解釈を持って実装したりしました。具体的な参考資料がないときも、品質を保ちながら形にする姿勢は、これからも大切にしたいです。
ナビゲーションの不具合から学んだこと
仕事では、GatsbyとReactで作られた自社サイトの不具合にも対応しました。ヘッダーのグローバルナビゲーションにホバーすると、サブメニューが表示されます。しかし、そのメニューは意図せず閉じることがありました。問題が起きていたのはローカル環境だけで、プレビュー、ステージング、本番環境では再現しませんでした。
調査では、GatsbyのLinkにホバーしたタイミングで、関連リソースの読み込み優先度が上がることを確認しました。その前後で親側の再描画が起きていることにも注目しました。
今回の実装では、親コンポーネントの中に中間コンポーネントが定義されていました。そのため、親が再描画されるたびに別のコンポーネント型として扱われ、再マウントが発生していました。その配下のstateも初期化され、開いていたサブメニューが閉じていたと考えました。1
Reactのstateの保持とリセット Reactは、UIツリー内の位置とコンポーネント型をもとにstateを保持します。親の中でコンポーネント関数を定義すると、再描画のたびに異なる型となり、配下のstateがリセットされる原因になります。
最初は、中間コンポーネントの定義を親の外へ移動すればよいと考えました。既存の構造をなるべく維持しながら、安全に直すことを目指した案です。
しかし、実際には型やHooksの構造まで変更する必要がありました。得られる成果に対して変更範囲が広くなり、コード量も増えました。想定していたほど単純で安全な修正ではありませんでした。
レビューでは、「そもそも、その中間コンポーネントは必要なのか。なくしてもよいのではないか」という案を提示されました。
中間コンポーネントは自分が作ったものではなかったため、既存構造として残す前提で考えていました。しかし、コードをもう少し広く読み、構造自体が必要なのかを疑えていれば、削除する選択肢にたどり着けたかもしれません。
調査し、修正案を考えることも自分の仕事でした。最終的には、自分の選択肢が既存構造を保つ方向に偏っていたことを反省しました。
コードを読むときの疑問を増やしたい
今回の経験から、コードの読み込みや情報の集め方がまだ甘く、狭い選択肢だけで判断してしまう弱さがあると感じました。既存構造を前提として受け入れ、構造そのものを疑う視点も十分ではありませんでした。
経験不足による部分もあり、すぐに解決できるものではありません。判断軸や選択肢を広げるには、ある程度の量をこなす必要があると思います。ただ漫然とコードを読むのではなく、「この症状の原因を理解し、問題を改善する」という具体的なテーマを持って読む方法が、自分には合いそうです。
コードを読むときは、次のような疑問を作っていきたいです。
- これはなぜ必要なのか
- この処理は何を守るためにあるのか
- なくした場合はどうなるのか
- 別の場所で解決できないか
- コードを足すのではなく、削除して解決できないか
- 自分の案より変更範囲の小さい方法はないか
しっかり理解しようとすれば、新しい疑問を作れるはずです。その疑問を一つずつ積み重ねながら、コードの構造と意図を深く読み解けるようになりたいです。
メンタルモデルをほかの判断と分ける
今回、考え方を整理する中で参考になった概念の一つが「メンタルモデル」でした。以前から言葉は知っていましたが、意味を十分に理解できていませんでした。
メンタルモデル システムがどのように動いているかについて、自分の中に持つ理解の枠組み。
当初は、「なぜそうするのかという考え方やコンセプトを、一言で表したもの」と捉えていました。しかし、エンジニアリングの文脈では、目的、原因の理解、修正方針、具体的な解決策を分けた方が考えやすいと気づきました。
今回の不具合に当てはめると、次のように整理できます。
- 目的：サブメニューが意図せず閉じる問題を直す
- 原因の理解・メンタルモデル：Reactは位置と型を基準にstateを保持し、型が変わるとstateをリセットする
- 修正方針・判断原則：変更範囲を小さくし、不要な構造を増やさずに直す
- 具体的な解決策：不要な中間コンポーネントをなくす
「最小限の変更で直す」は、メンタルモデルそのものではなく、修正方針や設計上の判断原則に近いものです。考える順番は、次のようになります。
目的 → 原因の理解（メンタルモデル）→ 修正方針 → 具体的な実装
言葉を分けることで、自分が今どの段階について考えているのかを確認しやすくなりました。
レビューで知らない選択肢を示されたとき
今回のレビューを抽象化すると、「AではなくBにした理由は何か」と聞かれた形になります。しかし、自分はBという選択肢を思い浮かべていませんでした。
Aについては、その時点で調べられた情報をもとに、できる限り理解して出した案でした。一方、AIも使って調査していたため、「AIが出したコードを理解せずに使っている」と見えたのではないか、という不安もありました。
実際には、何も考えずに案を出したわけではありません。原因を調べ、既存構造をなるべく維持する方針でAを考えました。ただし、解決策を探す範囲や、自分の基礎力が不足していたことも事実です。
同じ状況になったときは、Aを選んだ理由、Bを選ばなかった理由、そもそもBを選択肢として認識していたかを分けて説明します。Bを知らなかったのであれば、もっともらしい比較理由を後から作らず、正直に伝えます。
Bの方法は検討できていませんでした。今回は、既存構造をなるべく維持しながら問題を直す方針で調べ、Aに至りました。Bの方が変更範囲を小さくできそうなので、そちらも確認したいです。Bで問題ないという理解で合っていますか。
レビュアーの案が、常に唯一の正解とは限りません。自分の案に理由があり、比較した上で別案を採用しない場合もあります。ただ、知らなかった選択肢を知ったのであれば、次から使える判断軸として自分の中に残せます。
レビューには、自分一人では発見できなかった選択肢や判断軸を知る役割もあります。知らなかったことだけを責めるのではなく、次の判断に生かすことを大切にしたいです。
これから意識したいこと
個人開発では、Lukurauhaのアーキテクチャとクライアント処理を見直します。Astroの機能を適切に生かしながら、自分が実際に使ったときの小さな違和感も拾い、読書体験を改善していきます。AI読書アシストについては、仮説を立て、実装し、試して改善するサイクルを回します。自分以外の人からフィードバックを得る方法も考えたいです。
仕事では、分からないことを適切なタイミングで質問し、聞きたい内容を整理して伝えます。セルフレビューを仕組み化し、依頼されたものを作るだけでなく、自分の意見や改善案も形にします。既存構造を守ることだけを前提にせず、不要なものを削除する選択肢も検討します。
まとめ
7月は、個人開発と仕事のどちらでも、考え方と判断の改善余地が残った月でした。
Lukurauhaでは、自分が長文を理解しながら読むための体験を考え始めました。仕事では、一つの不具合対応を通して、原因を理解するだけでなく、解決策の選択肢を広く持つことの難しさを知りました。
まだ知らない方法や、自分一人で思いつけない選択肢は必ずあります。すぐにすべてを判断できるようにはなりません。それでも、具体的な問題をテーマにしてコードを読み、疑問を重ね、レビューで得た視点を一つずつ自分の中に蓄積していきたいです。