744 Matching Annotations
  1. Jan 2026
    1. 「パッケージマネージャーの導入 ─ uv」「静的コード解析ツール ─ Ruff」「構造的パターンマッチ」「一歩進んだ型ヒントの活用」「テンプレート文字列リテラル ─ t-string」「コマンドラインツール – click」「TOMLファイルを扱う – tomllib」「非同期に対応したHTTPクライアント ─ HTTPX」

      節タイトルそのままだ冗長かなと思いました。

      パッケージマネージャーuv、とか、HTTPクライアントHTTPXとかでいいかなと

    2. はじめに

      生成AIが台頭している今のタイミングで本書を手に取る意味、みたいなことは書かなくてもいいかなぁ。 普遍的な知識をつけるとか?

    1. マネージャー LLM が各 Agent の成果物を確認し、妥当性をチェックしたうえで最終結果としてまとめる

      これは具体的になにをやっているのかちょっとわからなかったです。

      最後のブログ記事の内容を確認して、もともとのタスクの依頼内容を満たしているかをチェックしている? 満たしてなかったらどうなる?

    2. マネージャー LLM がタスク全体を把握し、実行計画をたてる

      ここもうちょい具体的に書いてくれた方が、コードをもとにCrewAIがなにをやってるか明確になると思いました。

      タスク全体をTaskの内容から把握し、実行計画を立てる。実行計画では◯◯調査、◯◯調査を実施し、その結果をもとにトレンド分析し~~

      書くAgentの役割や能力を踏まえ、各タスクを以下のように額Agentに割り当てる

      ◯◯調査、◯◯調査: データ収集専門家

      みたいな

    3. LLM やそのバージョンによって異なるため

      この説明だとLLMのバージョンが同じだったら同じ結果が返ってくると読める。

      実際には実行するたびに微妙に違う結果が返ってくるのでは?

    4. 実行したあとに幾つかログが抜粋で表示されていると、処理内容がイメージができていいかなと思いました。

      次の行に「ログには主に以下の情報が」と書いてあるので、ログの例がほしいと思います

    5. 各専門 Agent が Task 完了後に結果を マネージャー LLM に報告し、マネージャー LLM が最終成果物をユーザーに提出する

      シーケンシャルな場合との違いがあまりピントこなかったです

    6. # .env ファイルに環境変数を設定 OPENAI_API_KEY="your-openai-api-key" SERPER_API_KEY="your-serper-api-key"

      MUST: これだとコマンドラインで環境変数を設定しているように見える。コードブロックを分けた方が良い

    7. 以下に

      話が急に飛んでいる。

      一度見出し「◯◯の主な引数」みたいなのを挟み

      Agent、Task...には◯◯をするためにさまざまな引数があります。 以下に~~

      見たいな文章がほしい。

    8. SHOULD: コードの前に、どういうことをさせようとしているかの説明分がほしいです。 以下のコードのコメントを読めばわかるとは思うんですが、先に説明してからコードを読む方が、スムーズに理解できるかなと思いました

      たとえばこういう感じかなと

      最新のAI技術に対してわかりやすい記事を書くという目的で、調査員とライターの2人のメンバーがいて、調査員の調査した内容を元に~~~

    9. dotenv

      dotenvが必須かなと思ったけどそうじゃなくて環境変数を.envファイルに書きたいから使っているだけですよね。

      ここでは環境変数を.envファイルに書いて~~~のためにdotenvを使用します。

      みたいな説明がほしいかなと思いました

    10. 本記事では触れませんが、より高度な制御をすることが可能です。興味のある方は以下を参照してください。

      nits 箇条書きだと「体言止め」で文体が違うので、ここは普通の文章にした方がよいかと

  2. Dec 2025
    1. ファイルパス引数として存在することを確認

      上の文章と似た内容だけど微妙に情報が増えて箇条書きになっている。この箇条書きでなにを伝えたいかを直前に文章で書いて欲しい。

      以下は〜〜です。 以下に〜〜を示します。

      みたいな

    2. click.Choice(["txt", "md"]

      例なのでしょうがないけど、自分でファイル名を指定しつつ、拡張子も指定するというコマンドは、オプションの用途としてピンとこないなと思いました。

      何か数え方のルールとかを変えられるといいんだけど。文字数でカウントするかバイト数でカウントするか、とか

    3. オプションの後に値を指定しない。

      これはコマンドで呼び出すときの話ですよね?ちょっとこの文章だけだと意味が取りにくい

    4. 例えば、--nameオプションは名前を指定するために使用されます.

      これはなんか--nameは名前を指定するためだけにしか使われないように読めるので、ちょっと違うかなと。

      例えば、名前を指定するための--nameオプション、などです。

      とか?

    1. 実行環境のCPU数(os.process_cpu_count()が返す値)+4と32

      CPU数(長い文章)+4、と書いてあるのでそれがまとまりだとわかりにくいと思います。

      (os.process_cpu_count()が返す)実行環境のCPU数+4と32のどちらか

      だと読みやすいかな

    2. 未取得結果の最大件数を指定し、指定しない場合はすべての要素が即座にスケジューリングされる

      この表現ちょっとわかりにくいかなと思いました。

      buffersizeが指定されると、その数のプロセスやスレッドなどがスケジュールされ、それ以外は待ちとなる、ということですよね。

      「未取得結果の最大件数」という表現がわかりにくいなと思いました

    1. quote-style = "double" # 文字列をダブルクォートで統一する indent-style = "space" # インデントはスペ

      これデフォルト設定だからなー。 クォートをシングルにできるけど、設定なしの運用でいいんじゃない?みたいな記述がいいかなーって思ってます。

    2. これはストーリーとしては、この前に ruff check --fix を実行していないといけないので、そのように手前で実行している必要がある

    3. import sys import os

      使われていないモジュールだとF401が出ちゃうのでisortの意味がない(fixできない)

      無理やり使うモジュールを入れましょう

      datetimeとかなにかをいれてメッセージに追加する感じで

    4. またはruff.toml

      下の設定例だとpyproject.tomlなので

      前述の設定ファイルを用いて、にしてコードのキャプションに「説明 - pyproject.toml」とか書くのはどうでしょうか

    5. と、

      ここで、を打たないと「一部のルール」がFにもかかっているように読める。

      もしくはE系の一部とF系のルールが

      とか

    6. Ruffは、Astral社https://astral.shから提供さ

      他のライブラリとかでuvを使ったインストールには触れていないので、ここはなくてもいいかなぁ

    1. Resolved 29 packages in 11ms Installed 27 packages in 58ms (省略) + pytest-cov==7.0.0 (省略) + sphinx==9.0.4 (省略)

      ここも両方指定した場合と同じとか、まるっと省略してもいいかも

    2. olved 29 packages in 13ms Uninstalled 20 packages in 200ms Installe

      このへんも2回目以降は省略しちゃってもいいんじゃないかな

    3. uv pip list # パッケージ一覧を表示

      ここまでの手順を再実行すると多分この結果は得られないはず。手前で環境作り直すとかした方がいいかも?

    4. 現在インストールされているPython環境の一覧を出力する

      インストール可能な一覧とインストールされていたらその場所を出力している

    5. 現在インストールされているPython環境の一覧を出力する

      インストール可能なPythonの一覧を出力する。が正しいです

      List the available Python installations

    6. uvの主なコマンド

      本書で紹介するuvのコマンド

      でいいかな。主なというよりはこの書籍で紹介するものを列挙していると思うので

    7. アンインストール

      addは追加するだけどremoveはアンインストールするなので表現が揃っていない。 追加/削除 or インストール/アンインストールに揃えて欲しい

    8. この手順よりは、新規にディレクトリ作成、uv init実行した後に、pyproject.toml, uv.lockだけコピーしてuv sync実行するみたいな手順がいいのではと思った。

      実際のユースケースに合わせる

    9. uv pip installした場合はuv addと違ってpyproject.tomlとかuv.lockが更新されないということを書いた方がいいかなぁ

    10. uv.lockの更新があるかを事前に調べる

      pyproject.tomlの設定を見て、今のuv.lockファイルに存在するパッケージのままか新しいバージョンが存在するかを調べる。

      みたいな意味合いだと思います。

      あと、これってどっちかというと hoge>4.0.0 とかかいていて、hogeの最新バージョンがでているか(pip list -O)みたいな使い方がメインかなと思ったんですが、そうではない?

      pyproject.tomlを書き換えたのはここで例として示しているために必要なだけど、本来はpyproject.toml書き換えたらuv syncの方を使うかなと思ったので(uv 素人なのではずしてたらすいません)

    11. 依存関係にある

      依存関係というよりも、「さきほど追加したパッケージが」とかいう説明でよいのではないか

    12. Pythonパッケージがイ

      pipコマンドと同様に、とかあってもいいかも

      PyPIからダウンロードしてインストールされていることとか触れて欲しい。

    13. 依存関係を管理する

      依存関係を管理するってちょっとイメージしにくいかなと思いました。

      プロジェクトで使用するライブラリを管理する、とか?

    14. uv-example

      さっきとは異なるディレクトリに作ったと言うことですかね。手順で mkdir uv-example がないのでちょっと混乱するかも

    15. 「A virtual environment already exists at `.venv`. Do you want to replace it? [y/n]」という

      長いし、トルでも意味は通じるかなと

      確認するメッセージが表示されます。

    16. 仮想環境を有効化した場合は、プロンプトにプロジェクト(ディレクトリ名)が表示されることにも言及して欲しい。

      venvは作成したvenv名がプロンプトで表示されていたので

    17. uv init

      この手前に全体を俯瞰したいので、uvで提供しているコマンド一覧がほしい。

      全部紹介しないなら、そのうち本書ではこれを紹介するよ、とか言ってほしい

    18. 特定のバージョンのuvをインストールする場合は

      これ必要な場合ってありますか?説明しなくてもいいかなと思った

    19. Pythonの標準パッケージマネージャーはpipですが、

      pipはパッケージインストーラーであってマネージャーじゃないかなという意見

      https://pip.pypa.io/en/stable/

      あー、でもpipの方に「パッケージを管理する」って書いてるのか、じゃあこのままでいいかなぁ

    1. 誤差が出てもエラーにはならないため

      これはよくあるエラーなのか?

      よくあるエラーだと上にあるTOMLDecodeErrorが出るから、それを見てちゃんと対処してね、っていう話が適切かなと思いました。

      どっちかというと周辺知識よりかなと思いました

    2. PEP 680においても、パッケージングツールなどでTOMLを読み込むことを目的としていることから、書き込みの必要はないとされています。 その理由としては、以下のようなことがあります。 TOMLのスタイル(インデントや引用符など)にゆらぎがあり、標準化しづらい コメントや書式などのスタイル関連のメタデータを含んだ出力を行うAPIの設計が複雑 現時点では除外する方向として、将来的に再検討する方が安全

      ちょっと読みにくいかなと思いました。

      PEP 680においても、以下の理由によりTOMLの読み込みのみで書き込みには対応しないことと記述してあります。

      • ~~標準化が困難
      • ~~設計が複雑
      • ~~将来的~~安全
    3. 挙げれています。

      挙げられています。

      最後までよんでPEPの話だと思ったので、この文の最初に

      PEP 680中ではtomllibを標準ライブラリとする理由として~~~が挙げられています。

      みたいに書いた方がいいかなと思いました。

    4. パッケージングに選ばれている

      パッケージに関する情報を記述するpyproject.tomlの

      とか?(ちょっと表現がふわっとしている&省略されているかなと思った

    5. サポート

      サポートが連続するので言い換えたい。

      プログラミング言語にTOMLファイルに対応したライブラリがあります。

      とか

    1. Required/NotRequiredの例

      サンプルコードがちょっとわかりにくいかなと思いました。

      基本的には必須で、任意のフィールドがあるときは NotRequired を指定する

      逆に、ほとんど任意で一部必須の場合には、total=Falseを指定して、必須のフィールドにのみRequiredを指定する

      だと思うので、この2つを分けて説明するのがいいと思います。

    2. そのまま維持したままラップしたいとき

      nits: まま、が連続するので冗長かな

      「引数を維持したまま」で意味は通じそう

  3. Nov 2025
    1. 前述の「Pyreflyの使い方」で使ったサンプルコードを対象に

      これだと短すぎるので、なんかのリポジトリをまるっと型チェックとかする方がいいかなと思いました

    2. example.py

      このリンクがわかりにくいので、説明を書いて欲しいかな。

      サンドボックスでexample.pyを◯◯した結果

      みたいな

    3. 動作する

      nits: 体言止めと~~するがまざっているのでどっちかに統一がいかな

      高速に動作 付ける機能

      でよさそう

    4. あとで比較対象にもなっているので、「型チェッカーにはmypy、pyrightなどがありますが、Pyrefryには◯◯な特徴があります」みたいな感じの文章があるといいなと思いました