## はじめに

Anthropicが提供するCLIベースのAIコーディングエージェント「Claude Code」を使った開発ワークフローをご紹介します。

Claude Codeの特徴は、ターミナル上で動作し、GitHubのISSUEやPRと直接連携できる点です。これにより、ISSUEを起点とした開発フローを非常にスムーズに進めることができます。

## Claude Codeとは

[Claude Code](https://docs.anthropic.com/ja/docs/claude-code/overview)は、Anthropicが提供するCLIベースのAIコーディングエージェントです。ターミナルから自然言語で指示を出すだけで、コードの生成・修正からGit操作まで一連の開発作業を自律的に進めてくれます。

Claude Codeの基本的な使い方やインストール方法については、[前回の記事「Claude有料版を初めて使う開発者向けガイド」](/blog/blog-32/)で詳しく解説していますので、そちらをご覧ください。

本記事では、Claude Codeの中でも特に強力なGitHub連携機能を活用した「ISSUE駆動開発」のワークフローに焦点を当てて紹介します。

## ISSUE駆動開発とは

ISSUE駆動開発は、ISSUEを起点として開発を進める手法です。GitHubやGitLabなど、ISSUEトラッカーを持つサービスで実践できます。すべての作業がISSUEに紐づくため、以下のようなメリットがあります。

- トレーサビリティ: なぜその変更が行われたかが明確
- チーム連携: 作業状況の可視化と共有が容易
- 品質管理: レビューとテストのプロセスが明確

## Claude CodeによるISSUE駆動開発ワークフロー

Claude Codeを使うと、ISSUE駆動開発が驚くほどスムーズになります。以下に実際のワークフローを紹介します。

Claude CodeはCLAUDE.mdという設定ファイルでカスタマイズできます。今回のワークフローでは、CLAUDE.mdという設定ファイルに「ISSUEのURLが提供された場合はghコマンドで内容を確認する」といった指示を記述しておく必要があります。

### 1. ISSUEの確認と計画立案

```
> #123のISSUEに対応してください
```

このように指示すると、Claude Codeは以下を自動で行います。

1. `gh issue view 123` でISSUEの内容を取得
2. 要件を分析し、TODOリストを作成
3. 仕様や設計に不足があれば指摘し、見直しを促す
4. 作業計画を提示して確認を求める

ここで重要なのは、AIとの議論を通じて明確になった仕様や設計をISSUE側に反映させることです。これにより、ISSUEが単なるタスク管理ではなく、ISSUEが開発の意図や設計の背景を記録した、生きた仕様書として機能するようになります。

### 2. ブランチ作成と実装

計画が承認されると、Claude Codeは以下のワークフローを実行します。

1. フィーチャーブランチを作成（例: dev/123_add-user-validation）
2. 必要なファイルを特定し、コードを実装
3. 動作確認やテストを実行
4. 問題があれば修正を繰り返す

### 3. PRの作成とレビュー依頼

実装が完了すると、Claude Codeは変更内容をまとめたPRを自動作成します。

```
> PRを作成してください
```

PRには以下が自動で含まれます。

- 変更内容のサマリー
- テスト計画
- 関連するISSUEへのリンク

## やってみた所感

実際に3ヶ月間、このワークフローで開発を続けてきました。その中で得られた気づきを共有します。

### 既存プロジェクトへの導入のしやすさ

最も大きなメリットは、今まで使っていたGitHub ISSUEをそのまま活用できる点です。新しいツールやフローを導入する際、既存の運用を変える必要があると導入コストが跳ね上がりますが、Claude CodeはGitHubのISSUEを直接読み込んで内容を理解するため、既存のプロジェクト管理をそのまま維持できます。

この3ヶ月間、ほぼ全ての実装作業をClaude Codeに任せることができています。ISSUEを起点にした開発フローが確立されていれば、導入は驚くほどスムーズです。

### AIを信じて任せることの重要性

運用を続ける中で気づいたのは、細かくやり方を指示しすぎない方がAIの能力を発揮してくれるということです。

最初は「このファイルを開いて」「この関数を修正して」と細かく指示を出していましたが、それではAIの自律性を活かせません。「#123のISSUEに対応して」とだけ伝え、計画立案から任せる方が、結果的に質の高いアウトプットが得られます。人間が想定していなかったより良いアプローチを提案してくれることも少なくありません。

### 伴走スタイルがベストプラクティス

一方で完全に自律させるのではなく、あくまでも「伴走」というスタンスを維持することをおすすめします。

AIに複数のタスクを並列で任せたり、完全に放置して自律的に進めさせることも技術的には可能です。しかし、そうすると人間側のレビュー工数が一気に増え、かえって非効率になります。1つのタスクをAIと一緒に進め、要所要所で確認しながら進める「伴走スタイル」が、現時点ではベストプラクティスだと感じています。

「人間がISSUEを作成し、AIが実装する」という一方通行の役割分担ではなく、ISSUEを軸に人間とAIが協働しながら開発を進める。これがClaude Codeを活用したISSUE駆動開発の醍醐味だと感じています。

## まとめ

Claude Codeを使ったISSUE駆動開発は、開発ワークフローを大きく効率化する可能性を秘めています。特に、ISSUEの確認からPR作成までの一連の流れをAIがサポートしてくれることで、開発者はより本質的な設計や問題解決に集中できます。

設定ファイルを活用すれば、チームのコーディング規約やワークフローをClaude Codeに教え込むことも可能です。これにより、チーム全体で一貫した開発スタイルを維持しながら、AIの力を借りることができます。

AIコーディングエージェントはまだ発展途上ですが、開発者の強力なパートナーとなる未来は確実に近づいています。皆さんもぜひ、Claude Codeを使ったISSUE駆動開発を体験してみてください。

large_eyecatch.png

medium_eyecatch.png

small_eyecatch.png

thumbnail_eyecatch.png

eyecatch.png

Claude Codeで始めるISSUE駆動開発

## はじめに

GitHub Actions を利用する際、似たような処理を何度も記述していませんか？ ワークフローが複雑になるにつれて、メンテナンスコストが増大し、変更への対応も煩雑になりがちです。 
この記事では、GitHub Actions の処理を共通化することで、これらの問題を解決するための手法を、具体的な例を交えながら解説します。

## 再利用可能なワークフローによる共通化

まずは、<a href="https://docs.github.com/ja/actions/sharing-automations/reusing-workflows" target="_blank" rel="noopener noreferrer">ワークフローの再利用</a>を活用した共通化の方法を説明します。

**on** キーワードで、ワークフローを直接トリガーするイベントの代わりに **workflow_call** イベントを指定すると、別のワークフローからそのワークフローを呼び出すことができます。

**例: .github/workflows/deploy.yml**

```yaml
name: Deploy to Production

on:
 workflow_call: # ワークフローを再利用可能にするイベント
 inputs: # 呼び出し元のワークフローからパラメータを受け取る
 environment:
 required: true
 type: string
 target_host:
 required: true
 type: string

 secrets: # シークレットを受け渡す場合は明示的に指定する必要がある
 SSH_PRIVATE_KEY:
 required: true

 outputs: # 処理結果を呼び出し元のワークフローに返す
 deployment_status:
 description: "The status of the deployment job"
 value: ${{ jobs.deploy.outputs.status }}

jobs:
 deploy:
 runs-on: ubuntu-latest
 outputs:
 status: ${{ job.status }}
 steps:
 - name: Checkout code
 uses: actions/checkout@v4
 - name: Set up SSH
 run: |
 mkdir -p ~/.ssh
 echo "${{ secrets.SSH_PRIVATE_KEY }}" | tr -d '\r' > ~/.ssh/id_rsa
 chmod 600 ~/.ssh/id_rsa
 ssh-keyscan -H ${{ inputs.target_host }} >> ~/.ssh/known_hosts
 - name: Deploy to server
 run: rsync -avz -e "ssh -i ~/.ssh/id_rsa" ./ ${{ inputs.environment }}@${{ inputs.target_host }}:/var/www/html
```

上記のワークフローを呼び出すには、以下のように記述します。 
**jobs** セクションで新しいジョブを定義し、そのジョブ内で **uses** キーワードを使って、再利用可能なワークフローのパスを指定します。

**例: .github/workflows/deploy.yml**

```yaml
name: Deploy Application

on:
 push:
 branches: [main]

jobs:
 deploy-staging:
 uses: ./.github/workflows/deploy.yml # 共通化したワークフローのパス
 with: # 呼び出し元の inputs で定義した値を渡す
 environment: "staging"
 target_host: "staging.example.com"
 secrets: # 呼び出し元の secrets で定義した値を渡す
 SSH_PRIVATE_KEY: ${{ secrets.STAGING_SERVER_SSH_KEY }}

 deploy-production:
 uses: ./.github/workflows/deploy.yml
 with:
 environment: "production"
 target_host: "prod.example.com"
 secrets:
 SSH_PRIVATE_KEY: ${{ secrets.PRODUCTION_SERVER_SSH_KEY }}

 post-deployment-check:
 needs: [deploy-staging, deploy-production]
 runs-on: ubuntu-latest
 steps:
 - name: Check deployment status
 # 呼び出し元の outputs で定義した値を受け取る
 run: |
 echo "Staging deployment status: ${{ jobs.deploy-staging.outputs.deployment_status }}"
 echo "Production deployment status: ${{ jobs.deploy-production.outputs.deployment_status }}"
```

## Composite Action による共通化

次に、<a href="https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action" target="_blank" rel="noopener noreferrer">Composite Action</a> を活用した共通化の方法を説明します。

Composite Action は、通常のワークフローとは異なり、フォルダ階層は自由ですが、ファイル名は **action.yml** にする必要があります。 <a href="https://www.google.com/search?q=https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action%23creating-a-composite-action-within-the-same-repository" target="_blank" rel="noopener noreferrer">GitHub Docs</a> では、**.github/actions/{任意の名前}/action.yml** というフォルダ構成で作成することが推奨されています。

また、現時点では secrets の受け渡しはできません。 <a href="https://www.google.com/search?q=https://github.com/actions/runner/blob/main/docs/adrs/0549-composite-run-steps.md%23secrets" target="_blank" rel="noopener noreferrer">今後サポートされる予定</a> のようです。

**例: .github/actions/test/action.yml**

```yaml
name: "Node.js Test"
description: "Test implemented in node.js"
inputs: # 呼び出し元のワークフローからパラメータを受け取る
 working-directory:
 description: "Path to the working directory"
 required: true

outputs: # 処理結果を呼び出し元のワークフローに返す
 test_report_path:
 description: "Path to the test report file (if generated)"
 value: ${{ steps.report.outputs.test_report_path }}

runs:
 using: "composite" # Composite Action であることを宣言
 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Set up Node.js ${{ inputs.node_version }}
 uses: actions/setup-node@v4
 with:
 node-version: 22.X

 - name: Install dependencies
 run: npm install
 shell: bash # コマンド実行には shell を明示的に指定する
 working-directory: ${{ inputs.working-directory }}

 - name: Run tests
 run: npm run test --report_output=./test-results.xml
 shell: bash
 working-directory: ${{ inputs.working-directory }}

 - name: Set test report output
 id: report
 run: echo "test_report_path=$(pwd)/test-results.xml" >> "$GITHUB_OUTPUT"
 shell: bash
 working-directory: ${{ inputs.working-directory }}
```

上記の Composite Action を実行するには、以下のように記述します。

**例: .github/workflows/test.yml**

```yaml
name: Test Application

on:
 push:
 branches: [main]

jobs:
 test-app1:
 runs-on: ubuntu-latest
 steps:
 - name: Test
 id: test
 uses: ./.github/actions/test # 実行する Composite Action のディレクトリ
 with:
 working-directory: "./app1" # 呼び出し元の inputs で定義した値を渡す

 - name: Output test results
 # 呼び出し元の outputs で定義した値を受け取る
 run: cat ${{ steps.test.outputs.test_report_path }}

 test-app2:
 runs-on: ubuntu-latest
 steps:
 - name: Test
 id: test
 uses: ./.github/actions/test
 with:
 working-directory: "./app2"

 - name: Output test results
 run: cat ${{ steps.test.outputs.test_report_path }}
```

## どちらの方法を選ぶべきか

再利用可能なワークフローは、ワークフロー全体を共通化する仕組みです。 GitHub Actions は job 単位で別々のコンテナで実行されるため、共通処理内で変更した内容 (生成したファイルやインストールしたパッケージなど) は、後続の処理に引き継ぐことができません。

一方、Composite Action は step 単位で共通化するため、共通処理内で変更した内容は後続の処理に引き継がれます。 また、再利用可能なワークフローは実行のたびに新しいコンテナを立ち上げる必要があるため、単純で実行回数の多い処理の場合は Composite Action を利用することで、処理時間の短縮と料金の節約につながります。

以上の点を考慮すると、以下のように使い分けるのが適切です。

**再利用可能なワークフロー**

- 共通処理内で変更した内容を後続の処理に引き継ぐ必要がない場合（例: ビルド、デプロイ処理、セキュリティスキャンなど）
- 環境を変えて (Node.js のバージョンなど) 共通処理を実行する場合

**Composite Action**

- 共通処理内で変更した内容を後続の処理に引き継ぐ必要がある場合（例: 依存関係のインストール、環境設定、複数のコマンド実行など）
- 単純または実行回数の多い処理（例: テスト結果やデプロイ結果の出力、チャット通知など）

## まとめ

この記事では、GitHub Actions におけるワークフローの共通化手法として、再利用可能なワークフローと Composite Action の 2 つを紹介しました。

どちらの手法を選択するかは、共通化したい処理の粒度や、処理内で変更した内容を後続の処理で利用する必要があるかどうかなどを考慮して判断する必要があります。 これらの手法を適切に活用することで、ワークフローのメンテナンス性を向上させ、開発効率を高めていきましょう！

## 参考サイト

- <a href="https://docs.github.com/ja/actions/sharing-automations/reusing-workflows" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/sharing-automations/reusing-workflows</a>
- <a href="https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action</a>
- <a href="https://zenn.dev/moaikids/articles/32363c5386978e" target="_blank" rel="noopener noreferrer">https://zenn.dev/moaikids/articles/32363c5386978e</a>
- <a href="https://zenn.dev/kinjosan/articles/bd82e07aa69080" target="_blank" rel="noopener noreferrer">https://zenn.dev/kinjosan/articles/bd82e07aa69080</a>

small_github.png

thumbnail_github.png

github.png

GitHub Actions 共通化手法

今回は、GitHubの便利機能の紹介です！ 
⚠️現時点ではPublic Previewの機能紹介になります 


## こんな人向け

- 大規模なタスク/プロジェクトを分割して管理したい
- 分割したタスクを一目で進捗を見えるようにしたい

⚠️組織(organization)アカウントの人しか使えません


## Sub-Issues機能
GitHubでは、Issueに親子関係を作成することができ、Sub-Issue を Issue に追加することで、大きな作業をタスクに分割できます。 
Sub-Issue は、親の Issue との関係が表示されるため、GitHub 全体で作業を追跡できます。 
これにより、ビューの作成、親の問題によるフィルター処理、グループ化を行うことができます。

Sub-Issue 自体に Sub-Issue を含めることができるため、プロジェクト全体または作業の一部を視覚化し、Issue 間の関係を示す Issue の完全な階層を作成できます。

親 Issue ごとに最大 100 個のサブ Issue を追加でき、最大 8 レベルの入れ子になったサブ Issue を作成できます。 
つまり、最大100の8乗個のIssueを管理できます。

## Sub-Issueの作成手順
1. Issue画面の「Create Sub-Issue」から子Issueを作成できます。
2. Issue の説明の下部にある、[Sub-Issue の作成] をクリックします。
 
 ![](https://cont.sterfield.co.jp/uploads/1_a946d23684.png) 
3. テンプレートが準備されている場合には、ダイアログで、Issue のテンプレートを選択できます。
 
 ![](https://cont.sterfield.co.jp/uploads/2_fc9a7ceff4.png) 

4. 必要に応じて、Issueの情報を入力し、Issue の種類を設定し、 担当者、ラベル、プロジェクト、マイルストーンを設定します。 
 ![](https://cont.sterfield.co.jp/uploads/3_66a99f2eb1.png) 
## 既存の Issue を Sub-Issue として追加する方法
1. Issue画面の「Add existing Issue」から子Issueを作成できます。 
 ![](https://cont.sterfield.co.jp/uploads/4_cb14540079.png) 
2. Sub-Issue として追加する問題を選択します。
 ・提案の 1 つから Issue を選択します。
 ・[Issue の検索] フィールドに、Issue のタイトルまたは Issue 番号を入力し、結果をクリックします。
 ・他のリポジトリから Issue を追加するには、リポジトリ名の横にある をクリックし、別のリポジトリを選択します。
 ![](https://cont.sterfield.co.jp/uploads/5_59fafbf05a.png) 
子Issueが登録された親Issueには、子Issueの進捗状況が表示されます。 
 ![](https://cont.sterfield.co.jp/uploads/6_d5394fd099.png) 
 ![](https://cont.sterfield.co.jp/uploads/7_7c52dd58b2.png) 

## Sub-Issueの解除手順
1. Issue画面の解除したいSub-Issue横の[…]をクリックします。
2. 「Remove Sub-Issue」をクリックする
 ![](https://cont.sterfield.co.jp/uploads/8_c6aa8fc7e9.png) 
## まとめ
今までもISSUEの概要に書いたタスクリストからISSUEを生成する機能がありましたが、Sub-Issue機能の方がIssue同士のリレーションがしっかりしているので、確認する際に迷子になりづらい点がgoodです◎ 
そんな理由で、GitHubをチームで利用しているなら、必ず使ったほうがいい機能だと思いました。 
個人的には、Sub-Issue作ったタイミングで、自動的に親Issueに紐づいてくれたらいいのに。と思ったりしました（笑）

small_pixta_50037742_S.jpg

thumbnail_pixta_50037742_S.jpg

pixta_50037742_S.jpg

GitHubの便利機能紹介シリーズ「Sub-Issue機能」

## はじめに
この記事では、GitHubのリポジトリからステータスが"OPEN"のIssueを取得し、Googleスプレッドシートに追記する方法を紹介します。GitHubのREST APIを使用し、Google Apps Scriptを使って自動化します。これにより、特定の組織の複数のリポジトリからIssue情報を一括で取得し、追加の作業なしでスプレッドシートに保存できます。

ということで、前回の記事でGoogle Apps Script（GAS）をChatGPTに書いてもらったのですが、さまざまなことができることが分かったので、実際に業務で使っているGitHubとの連携を試してみました。
いくつか課題は残ったものの基本的な動作は確認できたのでそのGASそのものもシェア致します。

https://sterfield.co.jp/blog/18162/

## 必要なもの

### GitHubアカウントとアクセストークンの作成
 ![](/uploads/Fine_grained_Personal_Access_Tokens_861a8dbc65.png) 
GitHub >Setting>Developer Settings> personal access tokens >Fine-grained tokens
を選択します。
ここから新しいトークンを発行するのですが、我々の管理では、リポジトリは組織に紐づいているので、組織に対してのトークンと必要な権限、リポジトリのIssueの読み取り権限を設定します。

### Googleスプレッドシートの作成
最後にGASを共有していますが、スプレッドシートのIDが必要になります。
以下のようにd/と/editの間のXXXの値がスプレッドシートのIDになるので、控えておきしょう。

`https://docs.google.com/spreadsheets/d/XXX/edit` 

### Google Apps Scriptのセットアップ
 ![](/uploads/Chat_GPT_GAS_Google_1_8c0845570a.png) 
スプレッドシート＞拡張機能＞Apps Scriptで開いたページのコード.gs欄にベタっと貼り付けます。

## リポジトリの取得

ここから先のコードは、全てChatGPTから取得した末尾にシェアしているものを記載します。

GitHubのREST APIを使用して指定した組織のリポジトリを取得する関数を作成する
リポジトリの一覧を表示するためのスプレッドシートの作成

## Issueの取得と追記

取得したリポジトリごとにステータスが"OPEN"のIssueを取得する関数を作成する
スプレッドシートにIssue情報を追記する

## 実行と結果確認

Google Apps Scriptの実行方法とトリガーの設定
スクリプトを実行し、Issue情報がスプレッドシートに追記されることを確認する

以下のように、取得はできたものの課題を残す結果となったので、課題点は後述します。

 ![](/uploads/Google_1c1a29f017.png) 


## エラーハンドリングの追加と問題解決のヒント
エラーが出たら、そのエラー文言をChatGPTに投げ、修正コードをもらっていくのですが、こんなお茶目な一面も。
 ![](/uploads/GAS_1ac28d726e.png) 

## 課題点

- 一度に取得できるIssueを増やす。ページングの実装なども追加したが、全件取得には至らなかった。この点は、GraphQLの書き方をChatGPTが提案してくれたが、どうにも上手くいかず、今回はREST APIでの手法となった。
- Projectsから課題を取得できないか。これは、Projectsがベータ版となっており、ChatGPTが2021年9月までの情報に留まっているため、断念。
- シート内の重複削除。そもそも全件取得が出来ていないので、未検証。

## まとめ
この記事では、GitHubのREST APIとGoogle Apps Scriptを活用して、GitHubリポジトリからステータスが"OPEN"のIssueを自動的に取得し、Googleスプレッドシートに追記する方法を紹介しました。これにより、開発チームやプロジェクト管理者は、リポジトリ内のオープンな課題を一元管理し、効果的に追跡することができます。さらに、自動化されたプロセスにより、作業の効率化とヒューマンエラーの軽減も期待できます。是非、この方法を試してみてください。

本当に革命的だなと思うのは、今までエンジニアに依頼するしかなかったような作業が非エンジニアである人間とChatGPTとの会話だけで出来てしまうところです。そして、このやり取りをしながら、指示を変えたりデバッグしていく作業はとても楽しいものでした。

そして、結構な時間をChatGPTと向き合ってきて、コツが分かってきたのですが、何かコードをもらう時に、一気に指示を出すのではなく、最初は最小単位で指示を出し、成功したら少しずつ機能を追加していくと、結局は近道です。
今回のケースですと、まずは、Githubから特定のリポジトリのIssueを取得。これが成功したら、ステータスをオープンに限定、複数のリポジトリから取得する、スプレッドシート側の重複をチェックするというように足していくと良かったです。

最後に今回のGASをシェアします。トークンやスプレッドシートのIDなどは、置き換えてください。 

## GAS

```
// カスタムメニューを作成する関数
function onOpen() {
 var ui = SpreadsheetApp.getUi();
 ui.createMenu('Custom Menu')
 .addItem('Fetch and Append Issues', 'fetchAndAppendIssues')
 .addToUi();
}
function fetchAndAppendIssues() {
 var organization = "your_organization"; // 組織名
 var spreadsheetId = "your_spreadsheet_id"; // スプレッドシートのID
 var sheetName = "your_sheet_name"; // 追加するシートの名前
 var status = "open"; // 取得するIssueのステータス
 var perPage = 100; // 1回のリクエストで取得するIssueの数（最大100件）

 var sheet = SpreadsheetApp.openById(spreadsheetId).getSheetByName(sheetName);

 var repositories = getRepositories(organization);
 var newData = []; // 新しいデータを格納する配列

 for (var i = 0; i < repositories.length; i++) {
 var repo = repositories[i];
 var page = 1; // ページ番号

 while (true) {
 var url = "https://api.github.com/repos/" + organization + "/" + repo + "/issues?state=" + status + "&per_page=" + perPage + "&page=" + page;
 var response = UrlFetchApp.fetch(url, {
 headers: {
 "Authorization": "Bearer YOUR_GITHUB_ACCESS_TOKEN" // GitHubのアクセストークン
 }
 });

 var issues = JSON.parse(response.getContentText());
 if (issues.length === 0) {
 break; // ページの結果が空ならループを終了
 }

 for (var j = 0; j < issues.length; j++) {
 var issue = issues[j];
 var title = issue.title;
 var number = issue.number;
 var createdAt = issue.created_at;
 var htmlUrl = issue.html_url;

 newData.push([title, number, createdAt, htmlUrl]); // 新しいデータを配列に追加
 }

 page++; // 次のページに進む
 }
 }

 if (newData.length > 0) {
 if (sheet.getLastRow() === 0) {
 sheet.getRange(1, 1, newData.length, newData[0].length).setValues(newData); // データを直接書き込む
 } else {
 sheet.getRange(sheet.getLastRow() + 1, 1, newData.length, newData[0].length).setValues(newData); // データを追記
 }
 }
}

function getRepositories(organization) {
 var url = "https://api.github.com/orgs/" + organization + "/repos";
 var response = UrlFetchApp.fetch(url, {
 headers: {
 "Authorization": "Bearer YOUR_GITHUB_ACCESS_TOKEN" // GitHubのアクセストークン
 }
 });

 var repositories = JSON.parse(response.getContentText());
 var repoNames = [];

 for (var i = 0; i < repositories.length; i++) {
 var repo = repositories[i];
 repoNames.push(repo.name);
 }

 return repoNames;
}
```

large__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

medium__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

small__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

thumbnail__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

_09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

GitHubリポジトリからIssueを取得してスプレッドシートに追記するGAS試作版を作ってみた

Blogブログ

Articles

Contact Us